Added parsing of Disk Start Number from Zip64 header if available

[darkms]

This PR fixes an issue reported in #194 - this was happening a the result of 2 problems:

1. My recent PR Fix central directory headers when Zip64 extension is applied #184 with a 'proper' (7-zip and WinZip friendly) way of writing Zip64 header, which have set Disk Start Number in Local & Central entry headers to 0xFFFF and populated the proper value to Zip64, have introduced an incompatibility of DotNetZip-generated zips with DotNetZip itself. 😄
2. Turned out we've never actually supported Disk Start Number in Zip64 header, the comment there stated that we don't support spanning zips, but actually we do

So... I've added the support for Disk Start Number in Zip64 header, it will only be used if it's available (to support more 'exotic' tools than WinZip) and if the Local/Central entry Disk Start Number was 0xFFFF (as prescribed by PKWARE spec).

I've tested my change with non-spanning zip case (new test) and spanning zip case - both can be read by DotNetZip just fine now.

[darkms]

I've also tested the change with WinZip-created zip spanning files using Zip64 (4.5GB span zip and several huge files so that they are split between those .zXX files).

[darkms]

This is more of a hotfix and generally a minor change, so I'm going to merge this now.

@haf FYI, but please let me know if you have any comments or a better solution in mind.