verify authentication code for zero-length winzip aes entries

[arshsmith1]

1. winzip_aes_decrypt only runs verify_hmac inside the len > 0 read branch, so a zero-length AES entry (comp_size == salt + password verify + hmac) never has its authentication code checked.
2. the central directory that supplies comp_size and crc isn't authenticated, so any encrypted entry can be rewritten to look empty with crc 0 and a garbage hmac, and it opens as a valid empty file instead of failing.

Verifying the hmac in ZIP_SOURCE_OPEN when data_length is 0 gets it rejected with ZIP_ER_CRC like any other tampered entry. The regress archive has an empty AES-256 entry with a corrupted hmac; reading it with the right password fails now and would pass before.

[dillof]

Thanks for the bug report and test case.

We've fixed it slightly differently so the error gets reported when closing the source (even without ever reading from it) instead of when opening it. This is in line with all the other end-of-file consistency checks done by sources.