Fix undefined left shift with signed ints

Caught by Clang's -fsanitize=shift.  A small unsigned int was promoted,
according to C's regular promotion rules, to a signed int, it was then
left shifted.  This sometimes pushed a 1 into the sign bit, which is
undefined behaviour.  Fix by using unsigned temporaries.
Fix cmake test builds when building as a sub-project
Run code coverage on your local machine

This change introduces a new make target called "coverage" it will
compile your code using special GCC flags, run the tests, and then
generate a nice HTML output.

This new make target will only be available if you build using GCC in
Debug mode.

To build the code coverage and open it in your browser do this:

    mkdir debug
    cd debug
    cmake -DCMAKE_BUILD_TYPE=Debug -DENABLE_COVERAGE=ON ..
    make -j20
    make coverage
    xdg-open coverage/index.html
Simplify passing of linker flags to try_compile calls

In commit d7bd02b6 (Modify CHECK_C_SOURCE_* checks to fix builds using
Visual Studio 12, 2013-02-01), commit e3d14342 (Set use of /SAFESEH linker
flag for all LIBARCHIVE_CHECK_C_SOURCE_* checks, 2013-02-01), and commit
58dc42aa (Fix checks for crypto algorithms in Visual Studio builds,
2013-02-01) we introduced and used custom copies of the CMake
CheckCSource(Compiles|Runs) modules in order to pass linker flags to
try_compile calls.  CMake has an issue tracker entry about passing
CMAKE_*_LINKER_FLAGS to try_compile calls:

  http://www.cmake.org/Bug/view.php?id=14066

Discussion there suggests a much simpler workaround: pass the flags
through the LDFLAGS environment variable.  Remove our custom check
macros and use the simpler workaround instead.
include linux/types.h on CentOS 5 in test_sparse_basic.c

Was getting this error:

In file included from ....../libarchive-3.1.2/libarchive/test/test_sparse_basic.c:44:
/usr/include/linux/fiemap.h:15: error: expected specifier-qualifier-list before ‘__u64’
/usr/include/linux/fiemap.h:26: error: expected specifier-qualifier-list before ‘__u64’


From https://groups.google.com/forum/#!msg/libarchive-discuss/691PHz5ENOc/4OzXBevG75AJ I see that the <linux/types.h> file is not included.

This fixed the problem for me on CentOS 5.8.
It was not visible as an issue on CentOS 6.3 or Ubuntu 10 or 12.

This change did not appear to break those already functioning platforms.
sha384 and sha512 are supported tags, add them to mtree.5.
"optional" is also supported, so add it to mtree.5.
Typo fix.
Document the "device" keyword and its value.
Add the device parsing logic. It allows mtree's libarchive to
parse device entries like NetBSD's mtree and its multiple possible
format: native, 386bsd, 4bsd, bsdos, freebsd, hpux, isc, linux, netbsd,
osf1, sco, solaris, sunos, svr3, svr4, and ultrix.
Start implementing the "resdevice" (resident device) keyword. It
corresponds to the st_dev field of stat(2), e.g. the ID of the
device that contains the inode.

Change parse_device() prototype so it can be used for "device"
and "resdevice", and call the appropriate archive_entry_set_{,r}dev()
function to store the field value.
Small typo fix in parse_device()'s description.
Implement "resdevice" and "inode" in the mtree(5) spec.
- resdevice is the keyword that corresponds to the "resident" device,
e.g. the one where the entry resides;
- inode is entry's inode number.
Document "resdevice" and "inode".
Bug fix (segfault): check filename against NULL in case we want
the output to go to stdout.
st_dev field corresponds to dev{major,minor} and not rdev{major,minor}.
Hide *lafe_progname and provide getter/setter instead.

This factorizes some code between binaries like bsdtar, bsdcpio, and
the soon-to-be mtree.
Show third party library versions in version string

Add a utility function, archive_version_details, to return a string
containing the libarchive version as well as the versions of third party
libraries such as zlib, bz2lib and liblzma.  Use this function for
bsdtar --version and bsdcpio --version.

http://code.google.com/p/libarchive/issues/detail?id=118
Use correct variable types for ASCII Windows functions.

There are both an ASCII and an Unicode variant for most of the Win32 API.
Fix some inconsistent uses.
Detect encrypted archive entries (ZIP, RAR, 7Zip)

With this change you can detect if an archive entry is encrypted. The
archive formats covered with this change are: ZIP, RAR, and 7zip. Other
formats can be added quite simply by looking at the already supported
formats. For all the already supported formats we have tests that check
if:

	* an archive entries's data is encryped (data test)
	* an archive entries's metadata is encrypted (header test)
	* one file is encrypted while another is not (partially test)

These new functions are introduced.

int archive_read_format_capabilities(struct archive*)

	Returns a bitmask of capabilities that are supported by the archive
	format reader. If the reader has no special capabilities,
	ARCHIVE_READ_FORMAT_CAPS_NONE is returned; otherwise 0 is returned.

	You can call this function even before reading the first header from
	an archive.

	Return Values:
	* ARCHIVE_READ_FORMAT_CAPS_ENCRYPT_DATA
		The reader supports detection of encrypted data.
	* ARCHIVE_READ_FORMAT_CAPS_ENCRYPT_METADATA
		The reader supports detection of encrypted metadata (e.g.
		filename, modification time, size, etc.)
	* ARCHIVE_READ_FORMAT_CAPS_NONE
		None of the above capabilities. If this value is returned, this
		doesn't mean that the format itself doesn't support any type of
		encryption it simply means that the reader is not capable of
		detecting it.

int archive_read_has_encrypted_entries(struct archive *)

	Returns "true" (non-zero) if the archive contains at least one
	encrypted entry, no matter which encryption type (data or metadata)
	is used; otherwise 0 is returned.

	You should only call this function after reading the first header
	from an archive.

	NOTE: I'm not sure that this function will stay in for long.

int archive_entry_is_data_encrypted(struct archive_entry*)

	Returns "true" (non-zero) if the archive entry's data is encrypted;
	otherwise 0 is returned. You can call this function after calling
	archive_read_next_header().

int archive_entry_is_metadata_encrypted(struct archive_entry*)

	Returns "true" (non-zero) if the archive entry's metadata is
	encrypted; otherwise 0 is returned. You can call this function after
	calling archive_read_next_header().

int archive_entry_is_encrypted(struct archive_entry*)

	Returns "true" (non-zero) if either the archive entry's data and/or
	it's metadata is encrypted; otherwise 0 is returned. You can call
	this function after calling archive_read_next_header().

If you use archive_read_format_capabilities() in combination with one of
the archive_entry_is_[data|metadata]_encrypted() functions, you can be
sure that you've encountered an encrypted entry. This allows you to
react differently depending on libarchive's return codes. For instance,
you might want to skip encrypted files from being extracted until
decryption support has been implemented.

Here's how I generated the 7zip test files:
-------------------------------------------

With header encrpytion (-mhe=on):

    $ rm -f test_read_format_7zip_encryption_header.7z
    $ echo "foo" > bar.txt && 7z a -mhe=on -p12345678 \
    test_read_format_7zip_encryption_header.7z bar.txt

    $ uuencode test_read_format_7zip_encryption_header.7z \
    test_read_format_7zip_encryption_header.7z > \
    test_read_format_7zip_encryption_header.7z.uu

Without header encrpytion (-mhe=off):

    $ rm -f test_read_format_7zip_encryption.7z
    $ echo "foo" > bar.txt && 7z a -mhe=off -p12345678 \
    test_read_format_7zip_encryption.7z bar.txt

    $ uuencode test_read_format_7zip_encryption.7z \
    test_read_format_7zip_encryption.7z > \
    test_read_format_7zip_encryption.7z.uu

Partially encrypted archive:

	$ rm -f test_read_format_7zip_encryption_partially.7z
	$ echo "foo" > bar_unencrypted.txt && 7z a \
	test_read_format_7zip_encryption_partially.7z bar_unencrypted.txt
	$ echo "foo" > bar_encrypted.txt && 7z a -mhe=off -p12345678 \
	test_read_format_7zip_encryption_partially.7z bar_encrypted.txt

	$ uuencode test_read_format_7zip_encryption_partially.7z \
	test_read_format_7zip_encryption_partially.7z > \
	test_read_format_7zip_encryption_partially.7z.uu

Here's how I generated the RAR test files:
------------------------------------------

These are the files we can will add to the archives:

    echo "data of foo.txt" > foo.txt
    echo "data of bar.txt" > bar.txt

 With header encrpytion (-hp):

    rm -f test_read_format_rar_encryption_header.rar
    rar a -hp12345678 test_read_format_rar_encryption_header.rar \
    foo.txt bar.txt

    uuencode test_read_format_rar_encryption_header.rar \
    test_read_format_rar_encryption_header.rar > \
    test_read_format_rar_encryption_header.rar.uu

Without header encrpytion (-p):

    rm -f test_read_format_rar_encryption_data.rar
    rar a -p12345678 test_read_format_rar_encryption_data.rar \
    foo.txt bar.txt

    uuencode test_read_format_rar_encryption_data.rar \
    test_read_format_rar_encryption_data.rar > \
    test_read_format_rar_encryption_data.rar.uu

Partially encrypted archive (-p on "foo.txt" and no password on "bar.txt"):

    rm -f test_read_format_rar_encryption_partially.rar
    rar a -p12345678 test_read_format_rar_encryption_partially.rar foo.txt
    rar a test_read_format_rar_encryption_partially.rar bar.txt

    uuencode test_read_format_rar_encryption_partially.rar \
    test_read_format_rar_encryption_partially.rar > \
    test_read_format_rar_encryption_partially.rar.uu

Here's how I generated the ZIP test files:
------------------------------------------

This is how I've created the test files:

These are the files we will add to the archives:
  On Windows:
    echo "data of foo.txt" > foo.txt
    echo "data of bar.txt" > bar.txt

For the creation of the Zip archives I've used the
PKZIP Command Line Add-On available from here:

http://comm.pkware.com/pkzip-cli-download.html

With header (aka central directory) encrpytion (-cd):

  On Windows:
    del /F test_read_format_zip_encryption_header.zip
    pkzipc.exe -add -cryptalgorithm=AES,256 -passphrase=12345678 -cd test_read_format_zip_encryption_header.zip foo.txt bar.txt

  On Linux:
    uuencode test_read_format_zip_encryption_header.zip \
    test_read_format_zip_encryption_header.zip > \
    test_read_format_zip_encryption_header.zip.uu

Without header encrpytion:

  On Windows:
    del /F test_read_format_zip_encryption_data.zip
    pkzipc.exe -add -cryptalgorithm=AES,256 -passphrase=12345678 test_read_format_zip_encryption_data.zip foo.txt bar.txt

  On Linux:
    uuencode test_read_format_zip_encryption_data.zip \
    test_read_format_zip_encryption_data.zip > \
    test_read_format_zip_encryption_data.zip.uu

Partially encrypted archive ("foo.txt" is encrypted and "bar.txt" is not):

  On Windows:
    del /F test_read_format_zip_encryption_partially.zip
    pkzipc.exe -add -cryptalgorithm=AES,256 -passphrase=12345678 test_read_format_zip_encryption_partially.zip foo.txt
    pkzipc.exe -add test_read_format_zip_encryption_partially.zip bar.txt

  On Linux:
    uuencode test_read_format_zip_encryption_partially.zip \
    test_read_format_zip_encryption_partially.zip > \
    test_read_format_zip_encryption_partially.zip.uu