Add RISC-V Zvbc accelerated CRC-32C implementation

Problem

MDEV-41115 added a hardware-accelerated CRC32C implementation for 64-bit RISC-V
processors supporting the Zbc extension, and MariaDB selects it whenever Zbc is
available at runtime.

Some RISC-V cores implement Zvbc (the vector carry-less multiply extension) but
not the scalar Zbc extension. In the RVA23U64 profile both Zbc and Zvbc are
optional extensions, so this combination is conformant.

On such a core MariaDB currently falls back to the slicing-by-4 crc32c_slow
path.

This task proposes adding a RISC-V Zvbc accelerated CRC32C implementation as the
accelerated path for those cores.

Proposed solution

Add an all-vector CRC32C implementation for 64-bit RISC-V systems with the Zvbc
extension. It uses the same 128-bit folding and Barrett reduction as the Zbc
implementation from MDEV-41115, expressed with vector carry-less multiply
instructions.

The proposed change includes:

• a RISC-V-specific Zvbc CRC32C implementation: K-lane vector folding with a
  4 lanes x 128-bit folding state, vlseg2e64 de-interleaved 64-byte loads
  and vclmul with a broadcast constant. All carry-less multiplication,
  including the Barrett merge, goes through the single-element vector form, so
  no scalar Zbc instruction is emitted anywhere in this compilation unit
• adaptive vector length: one e64m1 vector pair at VLEN >= 256, two vector
  pairs carrying the same 4 lanes at VLEN = 128, so 128-bit vector cores also
  execute the vector path at full width, with no scalar fallback
• build-time detection of Zvbc toolchain support, independent of the Zbc check
• a riscv_hwprobe-based runtime probe that distinguishes Zbc-only,
  Zvbc-only and both
• dispatch that prefers Zbc when it is available and selects the vector
  implementation only on cores that implement Zvbc but not scalar Zbc
• fallback to the existing implementation when neither extension is available

The change is intended for the main branch and does not change CRC32C
behavior on other architectures. It is independent of MDEV-41115 and can be
merged or reverted on its own.

Correctness

The implementation was validated against MariaDB's existing CRC32C
implementation.

The following tests passed:

• bit-identical to the Zbc implementation from MDEV-41115: same fold constants
  k1..k4, same fold order, same Barrett reduction
• check4K comparison against the slicing-by-4 slow path:
  slow = Zbc = Zvbc = dispatch, all matching
• MariaDB unittest/mysys/crc32-t.c: 36/36 tests passed
• RFC 3720 test vector: crc32c("123456789") == 0xE3069283
• boundary, unaligned and chained inputs handled correctly

Test platform:

Architecture: RISC-V 64-bit

CPU: Spacemit X100 (k3)

CPU cores: 8

Vector length: 256 bit (has both Zbc and Zvbc)

Compiler: GCC 14.3.0 (Ubuntu)

Performance

A microbenchmark was run on the same Spacemit X100 system, comparing the
proposed Zvbc implementation with MariaDB's existing slicing-by-4 CRC32C slow
path through the same my_crc32c interface.

Buffer       Existing slow    Zvbc      Speedup

             (MB/s)           (MB/s)

128 B        289              1147      4.0x

256 B        296              2105      7.1x

1 KiB        297              5466      18.5x

4 KiB        297              9116      30.7x

64 KiB       296              11398     38.7x

The Zvbc implementation provides approximately 4x-39x higher CRC32C throughput
for the tested buffer sizes.

These are local engineering measurements on the system described above and are
not intended as cross-platform performance guarantees.

Compatibility

The vector implementation is built only when the required RISC-V toolchain
support is available and is selected only when runtime Zvbc support is detected
and scalar Zbc is absent.

Systems without Zvbc continue to use the existing CRC32C implementation.
Non-RISC-V platforms are unaffected.

Existing Zbc deployments are unaffected: the dispatch prefers Zbc when it is
present, so a machine that has both extensions keeps using the optimized scalar
Zbc core. Measured on the same system before and after the change:

Buffer       Zbc baseline    dispatch     Difference

128 B        5540            5360         <= 4% (noise)

1 KiB        10277           10086        <= 2%

64 KiB       11687           11723        +0.3%

There is no API change and no change to the CRC32C values produced.