Start refactoring Zip writer:
 * Build list of entries for Central directory at entry_finish
   (So we can switch in-memory Central dir to a list of binary blobs.)
 * Rename some variables to clarify the code.
 * Add 'zip64' option to force zip64 extensions for testing
Adjust format for longer test names.
Support Zip64 extra data fields for handling large entries.

Process extra data fields for central directory and local file headers
so we get correct full size information in both cases.
Correct central directory vs. local file header sanity check
to compare full size information (including data picked out of
the extra data).

Note:  This does not yet support the Zip64 end-of-central-directory
marker so doesn't correctly handle very large archives.
Refactor Zip writer.

Zip writer no longer preserves full archive_entry objects for
every entry; it just accumulates the actual bytes to be put
into the central directory.  Most of the central directory file
header is formatted at the same time as the local file header.
The header formatting is refactored to make it easier to support
variable-length extra data.

The tests are adjusted to match the new output:  We include more
detailed extra data in the central directory, we're more selective
about generating data descriptors (they're not needed for directory
entries, for instance), UT extra data now includes only the time
fields specified by the user, we're setting the "version required"
field more accurately.

There are some initial attempts to include Zip64 extensions
when appropriate; that still needs lots of work.  I'm not
yet sure how to test Zip64 support without generating gigantic
archives.  Hmmm...
Remove the redundant test.
Remove deleted test from makefiles
gitignore all emacs backup files
Remove unused variables
Checkpoint work on zip64 support
Fix autotools build.

Follows commits 4e002d9a92ecd7cec0fb98b0bedbace8aad81f6e &
7a90710e0d3c786cf4f3af2457a815db6c9b5a5a that only handled CMake.
Fix issue 317

This is the exact same fix as mentionne din the GC issue,
cf. https://code.google.com/p/libarchive/issues/detail?id=317
Make the CMake build more pkg-config friendly

Build & install a libarchive.pc file, like autotools
Revert "Remove unnecessary windows.h include"

This reverts commit e6d1e13b2880ab0e6166e5ed168df7e6e0de943b.

We do need this (for the CLI tools).

Fixes a build failure on MinGW:
  CC       tar/bsdtar-bsdtar.o
In file included from tar/bsdtar_platform.h:62:0,
                 from tar/bsdtar.c:26:
./libarchive/archive_entry.h:250:64: error: unknown type name 'BY_HANDLE_FILE_INFORMATION'
 __LA_DECL void archive_entry_copy_bhfi(struct archive_entry *, BY_HANDLE_FILE_INFORMATION *);
                                                                ^
Better fix.

Restore e6d1e13b2880ab0e6166e5ed168df7e6e0de943b,
and make sure that we include windows.h earlier for the CLI tools.
Fix cpio build on MinGW.

Exact same concept as the previous commit.
Fix previous commit.

Forgot to check if cpio_windows.h actually pulled windows.h in ;p.
More MinGW trickery...

Poor man's attempt at making 4e002d9a92ecd7cec0fb98b0bedbace8aad81f6e
play nice with MinGW.
Dry coded for the fastest solution, there's probably a much better
way to handle that sanely & properly.
Make sure has_encrypted_entries is a signed int

Related to cd1740912b18f748a4f9b491a32b44c1712a7478

Trying to assign -1 (ARCHIVE_READ_FORMAT_ENCRYPTION_DONT_KNOW)
to a data type we're not sure will always be signed is a bad idea
(blew up on ARM, for instance).
Missed two tests!

(Mentioned in #58, thanks!)
Merge pull request #53 from NiLuJe/fix-issue-317

Fix issue 317