On my Ryzen 5900X system, baseline requires 16 byte loads per 16 byte
block. This can be rewritten to consolidate 4 loads of the first 4 bytes
into a single dword load. This resulted in a 5-10% throughput increase
in the benchmarks.

I have not benchmarked on big endian systems, but I suspect the
additional byte swap does not meaningfully reduce the win.

…#56)

`update_fast_16` dropped straight to the byte-at-a-time loop for anything
under 64 bytes. Keep the 4x unrolled 64-byte loop and add a 16-byte loop
after it, so only the final <16 bytes go through update_slow.

The fold body moves into an `#[inline(always)] fold_16` helper so both loops
share it. Bounds checks are fully elided: the generated code contains no
panic_bounds_check references, and the crate benches are unchanged.

55-70% faster on small and awkward inputs (16, 63, 100, 255 bytes),
13-24% on larger inputs with a tail (1000, 4095), and neutral on exact
multiples of 64.

Also adds `s390x-unknown-linux-gnu` to the cross-test matrix: every existing
target is little-endian, so nothing in CI exercises the big-endian paths.
The decode here is explicitly little-endian (`from_le_bytes` plus indexing)
and is endianness-independent by construction, but that was untested.

Idea and initial benchmarks from #60.

Co-authored-by: chiri <chirizxc@proton.me>