fix modifying existing zipfile with zip64 enabled

The local header size computed from the central directory entry
is incorrect due to the Zip64Placeholder in the local entry.
This caused us to seek to the wrong location when copying an
unchanged compressed data stream.

(The same problem could occur when modifying any zip file where
the local header and central directory header contain different
variable-sized fields, so it's a good idea not to trust the CD
to tell us the local header size in any case.)
remove Zip64Placeholder

and just use Zip64 extra information headers unconditionally.
only require zip64-compliant version_needed_to_extract if
the archive or a file's uncompressed size exceeds 4GB.
otherwise down-level extractors can ignore the Zip64
extension just as well as they can ignore the placeholder.
fix FULL_ZIP64_TEST

this test fails if zip64 write support isn't enabled
write zip64 central directory only if necessary

to improve compatibility with down-level zip extractors.

also, don't write zip64 central directory if zip64 write support
is not enabled.
only write zip64 central directory if zip64 support enabled
qualify namespaces in zip64_full_test
Merge pull request #142 from jstanley0/zip64-commit-fix

fix modifying existing zipfile with zip64 enabled
Update .travis.yml
Version bump
remove Zip64Placeholder; always use zip64 in local entry

if zip64 write support is enabled, use zip64 local entries
unconditionally instead of reserving space for them via a
non-standard placeholder.  use zip64 in central directory
only if necessary.