RISC-V RVV optimization (UTF-16 inputs)

[s1amese2003]

What

Adds a RISC-V Vector (RVV) backend for the existing char16_t SIMD fast path, mirroring the SSE2/NEON implementations (#198, #209): load 8 UTF-16 code units, check that all are ASCII digits, then narrow and hand the packed bytes to the existing SWAR parser.

Enabled when the compiler targets the full V extension (__riscv_v, which guarantees VLEN >= 128) and provides version 0.11+ of the RVV intrinsics (__riscv_v_intrinsic >= 11000, the version that introduced the __riscv_-prefixed spellings — GCC 13+, Clang 16+). Without the V extension the scalar path is used, as before.

CI

• The RISC-V workflow configured without -DFASTFLOAT_TEST=ON, so its ctest step had no tests to run (the other emulated-arch workflows, s390x and alpine, do pass it). This PR turns tests on so the new code is actually exercised under QEMU.
• Added a second QEMU pass with vlen=256 to cover a different hardware vector length; rvv_ta_all_1s=on poisons tail lanes in both passes.
• Renamed the workflow "Ubuntu RISC-V rvv VLEN=128 (clang 17)" -> "Ubuntu RISC-V rvv (clang 17)" since it now tests two VLENs — if a required status check is keyed to the old name, feel free to drop that hunk.

Testing

• Full test suite passes under qemu-riscv64 (clang 17, -march=rv64gcv) at both VLEN=128 and VLEN=256, and natively on x86_64.
• The compiled kernel is the direct analog of the NEON path: vsetivli zero,8,e16,m1 ; vle16.v ; vsub.vx ; vmsgtu.vi 9 ; vfirst.m ; vnsrl.wi 0 ; vse8.v.
• Also compiles cleanly with GCC 13.3 / GCC 14.2 (-Wall -Wextra, C++11 and C++17 modes), with -march=rv64gc (no V — scalar fallback), and for rv32gcv.

I don't have RVV silicon, so I can't provide hardware benchmarks — happy to adjust anything if you can bench it on real hardware.

Fixes #343