hashing/crc32c: make the backing implementation a template parameter

crc::crc32c wrapped google/crc32c with no way to substitute another
implementation. Turn the wrapper into basic_crc32c<Backend>, add
backends for google/crc32c and abseil's absl::ExtendCrc32c, and make
crc::crc32c an alias for the abseil instantiation, so production
switches over with no call site changes.

Abseil extends buffers of 64 bytes or less inline instead of
dispatching through an out-of-line call behind a runtime CPU check.
That is the shape of most of our checksumming, so the wins land where
we spend the time:

  batch header (12 integer extends)   33.5ns -> 2.2ns
  64KiB iobuf in 512 byte fragments    4.55us -> 2.44us
  8 byte buffer                        2.69ns -> 1.32ns
  512 byte buffer                     26.96ns -> 14.96ns

Bulk throughput above 4KiB is a wash: google/crc32c is up to ~3%
faster at lengths just above one of its block tiers (4096, 16384) and
up to ~15% slower just below one (4032, 16256); abseil has no such
cliffs. Note abseil currently picks its no-PCLMULQDQ fallback on hosts
its CPU table does not recognize, so the mid-size numbers are a floor
rather than the best it can do.

Backends produce identical values, which is what makes the switch
safe: crc32c values are persisted in storage indices, snapshots and
sst footers, and are part of the Kafka record batch wire format. The
tests and benchmark added by the next commits pin both backends to the
RFC 3720 vectors and are the source of the numbers above, measured
through this wrapper.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>