Recognize riscv64 targets in CMake

[carlosqwqqwq]

Why

c-blosc2 already has generic shuffle and bitshuffle implementations, but its top-level CMake logic still treated riscv64 as an unknown processor and only reported that hardware-accelerated implementations were unavailable. This patch makes the RISC-V target explicit and documents that the build should use the generic path instead of pretending the target is unsupported.

What changed

• Add an explicit riscv32 / riscv64 / riscv branch in the top-level CMake processor detection.
• Force x86, ARM NEON, and ALTIVEC feature toggles off for RISC-V targets so the generic shuffle path is selected deterministically.
• Replace the generic unknown-processor warning for RISC-V with a status message that explains the expected generic fallback behavior.
• Keep the patch conservative: it does not add RVV intrinsics or any RISC-V-specific codec optimization.

Verification

• Ran native CMake configuration with Ninja on the local Windows host using BUILD_TESTS=OFF, BUILD_FUZZERS=OFF, BUILD_BENCHMARKS=OFF, BUILD_EXAMPLES=OFF, BUILD_PLUGINS=OFF, BUILD_SHARED=OFF, and BUILD_STATIC=ON.
• Built the native tree successfully with cmake --build build-codex-native --parallel 4.
• Ran simulated riscv64 CMake configuration with CMAKE_SYSTEM_NAME=Linux, CMAKE_SYSTEM_PROCESSOR=riscv64, CMAKE_TRY_COMPILE_TARGET_TYPE=STATIC_LIBRARY, and forced __riscv=1 / __riscv_xlen=64 because no real RISC-V toolchain is available on the host.
• Built the simulated riscv64 tree successfully with cmake --build build-codex-riscv --parallel 4.
• Confirmed the simulated riscv64 configuration prints Detected RISC-V target; hardware-accelerated shuffle implementations are not available, so the generic path will be used.
• Checked build-codex-riscv/build.ninja: it does not contain shuffle-sse2.c, bitshuffle-sse2.c, shuffle-avx2.c, bitshuffle-avx2.c, bitshuffle-avx512.c, shuffle-neon.c, shuffle-altivec.c, -msse2, -mavx2, -mavx512, or arch/x86 sources.

Notes

This is a conservative portability patch. It only makes RISC-V target handling explicit and keeps c-blosc2 on its existing generic code path. Verification covers native build stability plus simulated RISC-V configuration and source-selection checks, but not a real riscv64 cross-toolchain build or hardware run.