Add RISC-V Vector Extension implementation of from_chars

[e4d08]

This adds a RISC-V Vector (RVV) implementation of the from_chars algorithm, ported from the x86 SIMD implementation. The implementation supports VLEN >= 128 and handles narrow and wide character types (char, char16_t, char32_t).
This PR is heavily inspired by Andrey Semashev's work on x86 SIMD implementations.

The performance effect on Spacemit-X60 (riscv64), gcc 16.1.0, in millions of successful from_chars() calls per second:

Char     | Generic | RVV
=========+=========+================
char     |  4.123  | 11.249 (2.73x)
char16_t |  4.117  |  9.128 (2.22x)
char32_t |  4.301  |  7.754 (1.80x)

The unsuccessful parsing case depends on where the error happens, as the generic version may terminate sooner if the error is detected at the beginning of the input string, while the SIMD version performs roughly the same amount of work but faster. Here are some examples for 8-bit character types (for larger types the numbers are more or less comparable):

Error              | Generic  | RVV
===================+==========+================
EOI at 35 chars    |   3.782  | 10.109 (2.67x)
EOI at 1 char      | 145.204  | 10.998 (0.08x)
Missing dash at 23 |   6.625  | 11.329 (1.71x)
Missing dash at 8  |  17.294  | 11.575 (0.67x)
Illegal char at 35 |   4.354  | 10.720 (2.46x)
Illegal char at 0  | 106.487  | 11.016 (0.10x)

Early errors (EOI at 1 char, illegal char at 0) are significantly slower with RVV — the 1-character input cannot amortize the SIMD setup cost, resulting in a ~13x slowdown. This is consistent with the x86 implementation's behavior, which shows the same pattern.
The missing dash at position 8 case shows a slight regression (0.67x), unlike x86 which achieves a speedup for this scenario. This is likely because the RVV implementation uses two separate expected dash vectors — one per deinterleaved character pair — rather than x86's single shuffled vector. The early error at position 8 does not recoup the overhead of this approach.
Late errors and successful parses all show worthwhile speedups ranging from 1.71x to 2.73x. In general, for inputs where the SIMD path can reach its full processing width, the RVV implementation provides a consistent ~2x improvement over the generic path across all character types.
The test code that was used for benchmarking is the same as the one in PR #186 (with running the successful parse twice for warmup):
uuid_from_chars_perftest.cpp

Compile and run with:

g++ -O3 -march=rv64gc -std=gnu++17 -I. -o uuid_from_chars_perftest_generic uuid_from_chars_perftest.cpp
g++ -O3 -march=rv64gcv -std=gnu++17 -I. -o uuid_from_chars_perftest_rvv uuid_from_chars_perftest.cpp

taskset --cpu-list 1 ./uuid_from_chars_perftest_generic 
taskset --cpu-list 1 ./uuid_from_chars_perftest_rvv

[pdimov]

That's interesting but we need a way to test it.

[e4d08]

I could add RISC-V tests to the CI, but I need your opinion on the best way of doing it. I consider cross-compiling and running tests under QEMU, but maybe there are better options. If cross-compiling is eligible, let me know and I will implement it.

[pdimov]

I don't know of a better way, so we could try that. But please use a separate PR for it.

[e4d08]

@pdimov Hello! Testing is ready at #197. Is there anything else needed?

[Lastique]

Looks good to me.