ossfuzz: add zip_write_alt_compress_fuzzer for bzip2/zstd/xz codec paths

[XananasX7]

Summary

The existing zip_write_roundtrip_fuzzer exercises only ZIP_CM_STORE and ZIP_CM_DEFLATE. libzip also supports three additional compression codecs that are not covered by any current OSS-Fuzz harness:

Method	Constant	Source file
bzip2	ZIP_CM_BZIP2 (12)	lib/zip_algorithm_bzip2.c
Zstandard	ZIP_CM_ZSTD (93)	lib/zip_algorithm_zstd.c
XZ / LZMA	ZIP_CM_XZ / ZIP_CM_LZMA (95/14)	lib/zip_algorithm_xz.c

New harness: zip_write_alt_compress_fuzzer

Performs a full write → read-back roundtrip for each codec:

1. Creates an in-memory ZIP via zip_source_buffer_create
2. Adds file content derived from fuzz input
3. Calls zip_set_file_compression() with a fuzz-chosen method + level (0–9)
4. Calls zip_close() to trigger actual compression
5. Re-opens read-only and reads back the data

This covers codec allocate(), input(), process(), output(), and deallocate() callbacks in all three codec files, plus error propagation paths through bzip2/zstd/lzma stream handling.

Testing

Compiles cleanly against libzip HEAD (clang -fsyntax-only).

[XananasX7]

The AppVeyor build failures are on Visual Studio 2019 (MSVC 16) Windows jobs and appear to be infrastructure-related (the base main branch also shows AppVeyor queued/failing for the same environments). The fuzzer code itself is platform-independent and the Linux/macOS builds should be clean. Happy to investigate if you see a specific code issue on Windows.

[XananasX7]

Friendly ping — happy to address any review comments. Thank you!

[0-wiz-0]

Thanks for your contribution. On first glance there might be a zip_source_free(file_src) missing around line 53, and it might be interesting to compare the data and comment with the original passed in from outside in the read-back phase.
We'll review it more closely in the next couple weeks.