Fix two issues with cpuid_riscv64.c

Temporarily disable the CAXPY/ZAXPY kernels for C910V to workaround a CI hang

Merge risc-v branch to develop

Add CBLAS interfaces for BLAS extensions ?AMIN/?AMAX and C/ZAXPYC

utest: Add tests for zscal

Fixed handling of NAN and INF arguments when
inc is greater than 1.

LoongArch64: Handle NAN and INF

Loongarch64: amax and amin

No interface named {c/z}a{min/max}, keeping it would
cause ambiguity

Use +sve in arch declarations of the fallback paths for SVE targets

The forced values for LIBNAME were either riscv64_generic or c910v
while the non-forced value of LIBNAME was always riscv64.

The crash is reproducible when building OpenBLAS without forcing a
target in a riscv64 container running on an X86_64 machine with an
older version of QEMU, e.g., 7.0.0, registered with binfmt_misc to
run riscv64 binaries.  With this setup, cat /proc/cpuinfo in the
container returns the cpu information for the host, which contains a
"model name" string, and we execute the buggy code.  The code in
question is searching in an uninitialised buffer for the ':' character
and doesn't check to see whether it was found or not.  This can result
in pmodel containing the pointer value 1 and a crash when pmodel is
defererenced.  The algorithm to detect the C910V CPU has not been
modified, merely fixed to prevent the crash.

A few additional checks for NULL pointers are added to improve the
robustness of the code and a whitespace error is corrected.

Fix BLAS and LAPACK tests for RVV 1.0 target, update to 0.12.0 intrincics

Fix BLAS and LAPACK tests for C910V and RISCV64_ZVL256B targets

Fix BLAS, BLAS-like functions and Generic RISC-V kernels