Fix two issues with cpuid_riscv64.c

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.

Current RVV x280 target depends on vlen=512-bits for Level 3 operations.
Commit adds generic target that supports vlen=128-bits.
New target uses the same scalable kernels as x280 for Level 1&2 operations, and autogenerated kernels for Level 3 operations.
Functional correctness of Level 3 operations tested on vlen=128-bits using QEMU v8.1.1 for ctests and BLAS-Tester.

* fix multiple numerical stability and corner case issues
* add a script to generate arbitrary gemm kernel shapes
* add a generic zvl256b target to demonstrate large gemm kernel unrolls

Signed-off-by: Han Gao <gaohan@uniontech.com>

Signed-off-by: Han Gao <gaohan@uniontech.com>

Merge branch 'openblas-open-910' of git://github.com/damonyu1989/OpenBLAS into damonyu1989-openblas-open-910

Change-Id: Iae7800a32f5af3903c330882cdf6f292d885f266