fix: zero-length buffer panic and invalid empty-input compression

[AskAlexSharov]

Two correctness bugs in the CGo bindings, each with a regression test.

Bug 1 — zero-length dst panics instead of returning an error

Every compress/decompress method guarded only empty src, then took &dst[0] unconditionally:

if len(src) == 0 { return 0, nil }
... unsafe.Pointer(&dst[0]) ...   // panics when len(dst) == 0

So any call with a zero-length output buffer panicked with index out of range instead of the documented "output buffer too small" error. This is reachable through the public API — GzipDecompress(compressed, 0) allocates make([]byte, 0) and crashed the caller:

libdeflate.GzipDecompress(compressed, 0) // panic: runtime error: index out of range [0] with length 0

Each method now returns an error for an empty dst.

Bug 2 — compressing empty input produced an invalid stream

The compress methods short-circuited empty input to (0, nil), so GzipCompress(nil) returned a zero-byte slice. Zero bytes is not a valid gzip/zlib/DEFLATE stream — a standard decoder rejects it as truncated:

b, _ := libdeflate.GzipCompress(nil, libdeflate.DefaultCompression) // len(b) == 0
gzip.NewReader(bytes.NewReader(b))                                  // io.ErrUnexpectedEOF

The methods now pass empty input through to libdeflate, which emits a valid empty stream (~20 bytes for gzip). libdeflate handles this safely — deflate_compress_none special-cases in_nbytes == 0, and crc32(0, NULL, 0) reads nothing — so a nil data pointer is passed for empty src (taking &src[0] would itself panic).

Tests

• TestEmpty{Gzip,Zlib,Deflate}IsValidStandardStream — compress empty input and decode it with the standard library (compress/gzip, compress/zlib, compress/flate) to prove the output is a conformant stream, not just round-trippable by this package.
• TestZeroLengthDstReturnsErrorNotPanic — the six methods and GzipDecompress(_, 0) return errors instead of panicking.

All tests pass under go test -race; gofmt, go vet, and golangci-lint are clean.

Scope

Based on main. The runtime.SetFinalizer work on alex/compressor-finalizer is not included, so the finalizer-vs-KeepAlive premature-free issue is intentionally out of scope here.