feat(checksum): expose Crc32/Adler32 as public API behind a checksum feature

[MagicalTux]

The crate already carries a slice-by-8 IEEE CRC-32 and an RFC 1950 Adler-32 for the zlib/gzip trailers and rar3's filter recognition, but mod checksum was private, so callers could not reach them.

That gap has a cost. These codecs decode data streams, not container framing, so a caller that parses the container itself — a ZIP local header, a PNG IDAT chunk, a RAR file header — has to verify the checksum fields on its own, and had to pull in a second crate to do it.

The crate hit the same wall internally: src/xz/mod.rs keeps a duplicate byte-at-a-time CRC-32 with a comment explaining why —

// The wider crate has a `checksum::Crc32` but it is
// feature-gated to `gzip`; in an `xz`-only build we'd lose access,
// so we keep a self-sufficient copy here.

What this changes

A checksum feature that promotes the module to pub. Visibility is the only thing it changes:

• when a codec needs the module it is compiled either way — the feature does not add code to builds that already had it;
• each type keeps its existing per-codec gate, so a zlib-only build still doesn't carry the CRC table, and a gzip-only build still doesn't carry Adler-32;
• no alloc — both are plain u32 state machines, usable in no_std.

Crc32::reset was gated to gzip alone; it is now also available under the feature, so a caller can reuse one instance across members. The public methods gained docs and the module a doctest.

Verification

Confirmed from a scratch downstream crate that compcol::checksum is a compile error without the feature and works with it (Crc32 over "123456789" → 0xCBF43926, the CRC catalogue check value).

Built clean across: checksum alone (--no-default-features, no alloc), zlib-only, gzip-only, rar3-only, zlib+checksum, rar3+checksum, xz-only, and --all-features.

cargo test --all-features: 1767 pass, 0 fail. fmt clean; docs build clean with -D warnings.

Deliberately not included: switching xz (or bzip2, which uses a different polynomial) over to the shared implementation. That is a behaviour-neutral but perf-relevant refactor — xz's copy is byte-at-a-time, the shared one is slice-by-8 — and belongs in its own change.