fix(io): decode multi-member gzip input instead of truncating it

[BenjaminDEMAILLE]

Fixes #217.

The bug

flate2::read::GzDecoder decodes one gzip member and then reports EOF. Compressed input was
read through it, so a .gz made of concatenated members was silently truncated: no error, no
warning, just fewer reads. Multi-member gzip is not exotic here — it is what bcl2fastq writes,
what cat a.fq.gz b.fq.gz produces, and what every BGZF file is.

Measured on main with the bundled fixtures, where both files decompress to the same 12 lines
under gunzip:

Input	Number of input reads
single.fq.gz (one member, 3 reads)	3
multi.fq.gz (two members, 3 reads)	2

The fix

GzDecoder → MultiGzDecoder at the four read paths:

• src/io/fastq.rs — FASTQ input
• src/solo/whitelist.rs — barcode whitelist
• src/solo/count.rs
• src/bin/emptydrops.rs

No API change, no new dependency: the type ships in the flate2 version already in the tree.
MultiGzDecoder is a strict superset of GzDecoder for reading — single-member files decode
identically, which is why the existing test_fastq_reader_gzip still passes unchanged.

Test

test_fastq_reader_gzip_multi_member in src/io/fastq.rs writes two gzip members into one file and
asserts both reads come back. I checked it in both directions: it fails on the old decoder
(second gzip member must be decoded, not silently truncated) and passes on the new one.

Full local gate: cargo fmt --check clean, cargo clippy --all-targets -- -D warnings clean,
cargo test 631 passed / 0 failed.

Not in this PR

Compression is still detected by file extension (.gz / .gzip), so a compressed file with an
unexpected name is still read as plain text. Magic-byte sniffing and other input formats are #218.