RISC-V Vector (RVV 1.0) SIMD support

[mikey]

Adds a RISC-V Vector backend alongside the existing SSE/AVX/NEON/Altivec
paths, gated entirely on __riscv_vector + a new PFFFT_ENABLE_RVV
build define so the change is a no-op for every other target.

Two commits:

1. Add RISC-V Vector (RVV 1.0) SIMD backend — new src/simd/pf_rvv_float.h
   and pf_rvv_double.h, plus the matching include lines in
   pf_float.h / pf_double.h, the SIMD_*_HDRS listing in
   CMakeLists.txt, and a short README mention.
2. cmake: detect riscv64 and auto-enable RVV (+ CI job) — mirrors the
   aarch64/NEON auto-enable in cmake/target_optimizations.cmake, plus a
   new build_riscv64_qemu workflow that exercises the headers under
   qemu-user-static.

Design

• v4sf is a GCC vector_size typedef (16 bytes for float, 32 for
  double), which the compiler lowers to RVV instructions (vfadd.vv
  / vfmul.vv / vfmadd.vv / vrgather.vv / …).
• For float, SIMD_SZ=4 → 128-bit vector, works on any VLEN ≥ 128.
• For double, SIMD_SZ=4 → 256-bit vector, matching the AVX double
  layout. On hardware with VLEN ≥ 256 this is a single instruction;
  otherwise the compiler splits it into two ops. The build detects
  the host VLEN via a tiny try_run probe and appends a zvlNNNb
  token so the single-instruction form is used when available.
• Shuffles route through a PF_RVV_SHUF4 helper that picks
  __builtin_shufflevector (clang, GCC 12+) or __builtin_shuffle
  (older GCC), matching the same pattern used in src/sse2neon.h.
• The auto-detect also probes for the V extension itself: if it isn't
  present, the build falls back to plain rv64gc (no
  PFFFT_ENABLE_RVV, scalar path) instead of producing a binary that
  SIGILLs.

Verification

Tested on a SpaceMIT X100 (8 cores, VLEN=256, Ubuntu 26.04):

• gcc 15.2.0: ctest 13/13 pass; both test_pffft_{float,double} --test-simd exit clean (the shuffle/transpose self-tests).
• clang 21.1.8: same — ctest 13/13, both --test-simd pass.
  RVV throughput trails gcc by ~10–25 % (clang's shuffle lowering
  is less tight) but stays solidly above the scalar baseline.
• Auto-detect picks -march=rv64gcv_zvl256b and defines
  PFFFT_ENABLE_RVV; runtime pffft_simd_arch() reports "RVV",
  pffft_simd_size() reports 4.
• Explicit TARGET_C_ARCH=rv64gc builds cleanly and runs the scalar
  path — no spurious RVV define.

Performance vs the pure-scalar build
(-DPFFFT_USE_SIMD=OFF -DPFFFT_USE_SCALAR_VECT=OFF), real FFT,
PFFFT-U column, gcc 15.2, single core (taskset -c 0):

size	float speedup	double speedup
128	2.96×	2.05×
512	2.67×	2.32×
1024	2.78×	2.17×
4096	2.95×	2.20×
16384	2.62×	2.09×
65536	2.60×	2.04×

Complex FFTs see roughly 1.3–1.4× as expected
(memory-bandwidth bound).

Deliberately not done

• SIMD_SZ=4 is hard-coded throughout pffft's pass functions, so
  this backend stays at 4 lanes rather than scaling with VLEN.
  Using LMUL > 1 or a VLEN-agnostic refactor would need changes
  well outside the SIMD headers.
• No runtime CPU detection — PFFFT_ENABLE_RVV is decided at
  compile time, the same way PFFFT_ENABLE_NEON is.

What's tested vs not

• ✅ Native gcc 15.2 and clang 21.1.8 builds on real RVV 1.0
  hardware (correctness, --test-simd, performance numbers above).
• ✅ Explicit TARGET_C_ARCH=rv64gc (no-V) fallback path on the
  same hardware.
• ⚠️ The new build_riscv64_qemu CI job has not yet run on
  GitHub Actions; the first push may need toolchain/QEMU
  adjustments.

Happy to iterate on any of this — particularly the CMake glue and
the CI job — if there's a different shape you'd prefer.

Implementation done with Claude Code; see Assisted-by: trailers on the commits.