feat: complete and qualify hash variant APIs

[tisonkun]

Summary

• Implement all three original MurmurHash3 variants as allocation-free one-shot and streaming APIs.
• Name MurmurHash3 and XXH3 functions, states, and builders with their exact algorithm variants so callers do not need to remember an implicit default.
• Give complete-input hashing and incremental hashing separate, consistent entry points: module-level functions hash complete byte slices, while state types provide update, digest, and integration traits.
• Remove duplicate and legacy names without compile-time or rustdoc aliases; the renamed crate is presented as a fresh API.

Design Notes

MurmurHash3 now maps directly to the three names defined by the reference implementation:

Variant	One-shot	Streaming	Builder
x86_32	murmur3_x86_32	Murmur3X86_32	Murmur3X86_32Builder
x86_128	murmur3_x86_128	Murmur3X86_128	—
x64_128	murmur3_x64_128	Murmur3X64_128	—

The x86 and x64 labels select incompatible digest algorithms rather than restricting the Rust implementation to those target architectures; all three implementations are portable. The new x86_128 implementation follows the reference four-lane block, tail, and finalization order. Its one-shot and streaming results are checked against murmur3 0.5.2 across every length through 2 KiB, randomized inputs through 128 KiB, arbitrary streaming chunks, every two-way split through 257 bytes, and multiple seeds.

XXH3 likewise exposes xxh3_64 / Xxh3_64 and xxh3_128 / Xxh3_128. Xxh3_64Builder and Xxh3_64SecretBuilder are width-qualified because BuildHasher constructs only the 64-bit state. Xxh3Kernel, Xxh3SecretTooShort, and the secret constants remain unqualified because they are genuinely shared by both output widths.

Why remove associated one-shot methods?

A complete byte slice has one entry point: the corresponding module-level function. The removed state-associated methods were one-line forwarding wrappers with no state, configuration, validation, or behavior of their own. Keeping both forms made the API appear to offer two hashing modes and doubled the places users had to compare in rustdoc.

For FNV-1a specifically:

• Fnv1a32::oneshot(input) is covered by fnv1a_32(input).
• Fnv1a32::oneshot_with_offset_basis(input, basis) is covered by fnv1a_32_with_offset_basis(input, basis).
• Fnv1a64::oneshot(input) is covered by fnv1a_64(input).
• Fnv1a64::oneshot_with_offset_basis(input, basis) is covered by fnv1a_64_with_offset_basis(input, basis).

The state constructors, custom offset bases, update, digest, reset, builders, Hasher, and std::io::Write remain because they represent distinct configuration or integration capabilities. The same rule is applied consistently to MurmurHash3 and xxHash state-associated one-shot forwarding methods.

Validation

• cargo x lint
• cargo x check
• cargo x test
• One-shot x86_128 benchmark at 4 KiB / 1 MiB: rache median 8.70 / 8.81 GB/s; murmur3 reference path 4.47 / 4.56 GB/s on the development host