riscv64: 4 of 4: RVV element-wise and reduction kernels

[czoli1976]

Stacked on #2599, #2600 and #2601. GitHub cannot base a pull request on a fork
branch, so this targets main and its diff carries those PRs' commits too. The only
new commit here is 3bc03363 — the rest are reviewed in the three PRs above.

Stacked on the matmul tiers. Adds fifteen kernels: by-scalar and unicast
mul, add, sub, subf, min, max over f32, and the max, min and
sum reductions — filling the register_all_by_scalar / register_all_unicast
registries and the mul_by_scalar_f32, max_f32, min_f32, sum_f32 slots.

Two ways in which these differ from the matmul kernels

No VLEN predicate. They strip-mine on vsetvli instead of pinning vl to
a tile height, so vl is whatever the hart grants and the tail falls out of the
loop condition. That makes them vector-length agnostic outright — nothing to
gate beyond has_rvv(). nr is only the frame's chunking granularity here, not
a tile width.

No external assembler. They are Rust asm! blocks, as the corresponding
arm64 kernels are, so .option arch, +v goes through rustc's own LLVM and no
binutils version can refuse them. They therefore sit outside the tract_rvv
cfg, which records only whether an external assembler could handle the .S
matmul kernels. A toolchain too old for those still gets these.

The reductions keep the running result in element 0 of v1 and feed it back as
the reduction's scalar operand each round, so strip-mining needs no separate
accumulator vector and no final horizontal step — reduction operands are LMUL=1
whatever vtype says. vfredusum is the unordered sum, reassociating as the
arm64 kernels also do.

Testing

The frames' own proptests, with has_rvv() as the condition so they stay
meaningful on a hart without V. 2709 tract-linalg tests and tract-core's 270
pass at VLEN 128, 256 and 512, on stock RVA23, and with V absent, under qemu
10.2.1 and 11.0.3.

No CI change needed. Same caveat as the earlier PRs: correctness under
emulation, no hardware numbers.

🍍

[czoli1976]

@kali these PRs all use rafitied and stable ISA, no vendor specific extensions of any kind (it is quite fragmented with competing proposals and implementations for various extensions) so these PRs add Foundational Risc-V to extend the reach of TRACT to this platform and possibily invite other contributions from the community as the ISA standardisation evolves and solidifies. from a CI point of view QEMU is plenty to verify correctness, I have used both 10.X and 11.X). the fact it runs InceptionV3 executing end-to-end is quite remarkable.