Add RISC-V scalar fallback support

[carlos (carlosqwqqwq)]

Why

DirectXMath already has a complete _XM_NO_INTRINSICS_ scalar implementation. RISC-V consumers can opt into it with a build define, but __riscv is otherwise rejected by the header's target-selection logic. This patch makes that existing scalar implementation the conservative default for a recognized RISC-V target, so transitive consumers do not need to propagate a DirectXMath-specific define to every translation unit.

This is a default-selection and portability change, not a correctness requirement or a claim of optimized RISC-V support.

What changed

• Updated Inc/DirectXMath.h so __riscv selects the existing _XM_NO_INTRINSICS_ implementation.
• Added a short README note documenting that this path is scalar and provides no RISC-V vector or assembly optimizations.

Verification

• Built a real static riscv64 consumer with the dockcross/linux-riscv64 toolchain.
• Verified the output as a RISC-V ELF with file and readelf.
• Ran it successfully under qemu-riscv64; the smoke test exercised vector construction and addition, matrix scaling and transformation, and collision helpers.
• Rechecked the scalar implementation locally with GCC using _XM_NO_INTRINSICS_.

Scope

The patch intentionally does not add RVV intrinsics, assembly, a new backend, or RISC-V-specific handling to the x86 extension headers. If the project's policy is that scalar-only targets must explicitly define _XM_NO_INTRINSICS_, then the existing build define remains sufficient and this default-selection change is not necessary.

[carlos (carlosqwqqwq)]

@microsoft-github-policy-service agree

[Chuck Walbourn (walbourn)]

Why do you need to update the library instead of just defining -D_XM_NO_INTRINSICS_ in your build?

[carlos (carlosqwqqwq)]

You're right that defining _XM_NO_INTRINSICS_ is sufficient, so this change is not required to make a RISC-V consumer build.

The narrower rationale for handling __riscv in the header is to give a recognized target a consistent default. DirectXMath is header-only and is often included transitively, so otherwise every consumer build must know about and propagate a DirectXMath-specific macro to every translation unit. Selecting the existing scalar implementation avoids that integration requirement; it does not claim RISC-V intrinsics, RVV optimization, or comprehensive platform validation.

I have narrowed the PR accordingly: it now contains only the target-selection change and a short documentation note. I removed the CMake message and the RISC-V-specific changes to the x86 extension headers.

If the project's policy is that scalar-only targets should explicitly opt in with _XM_NO_INTRINSICS_, then the build define is the appropriate solution and the library change is not strictly necessary.