Issue #1055: Ignore padding in Zip extra field data

Issue #1055: Ignore padding in Zip extra field data

PKWare's APPNOTE.TXT simply documents the extra field
as a concatenation of <header><data> objects.  It does
not explicitly allow nor prohibit additional padding.

Libarchive originally treated any extraneous data in the
extra field as an indication of corruption and issued an
error.

However, some Zip writers do appear to include additional zero
bytes in the extra field and expect them to be ignored.
This works if:

 * We consider a field type of 0000 to be a padding field.
 * In particular, 0000 0000 is then a valid field with type zero
   and zero bytes of data.
 * If there are fewer than 4 bytes left at the end of the extra
   data (too few to be a valid extra field object), ignore it.

With the above conventions, zero padding can occur anywhere in
the extra field as long as the padding occurs in a multiple of
four bytes.  Any number of bytes can occur at the end:  groups
of four bytes will be skipped as valid empty fields; any final
group of less than four bytes will be simply ignored.

The test exercises all of the above options; the extra field data for
the file in this archive has:
 * Four zero bytes at the beginning
 * A valid UX field
 * A pad field of type zero with a non-zero length
 * An additional three final bytes

By verifying that the UX data was read correctly and that there
were no errors, we can be confident that all of the padding here
was handled correctly.