riscv_fpu: IEEE 754 conformance for the scalar FPU

[SolAstrius]

Summary

Bring RVVM's scalar F/D floating-point up to full IEEE 754 / RISC-V conformance. Against riscv-arch-test (ACT4) F, D, I and M with a Spike reference it goes from 101/260 to 260/260, with no change to any non-FPU behaviour.

This began as the #204 RMM (roundTiesToAway) fix and grew to close every remaining gap the conformance suite exposed.

What's fixed

• RMM rounding computed via exact error-free transforms, and the instruction's static rm field honoured (not just frm) for all arithmetic ops.
• FP-op dispatch no longer size-optimised (func_opt_size dropped) — roughly 2x interpreter FP throughput at zero size cost, since the FP path is not JIT'd.
• Canonical NaN results from arithmetic and FMA; mal-boxed narrow operands read as the canonical NaN; sqrt(-0.0) returns -0.0 without raising invalid.
• The FMA family: rounding mode honoured (including the fnmadd operand-negation fix), RMM exact ties via an error-free FMA, and the underflow flag set by true IEEE after-rounding tininess.
• fmul ties-away near the underflow boundary, where the Dekker product error itself underflows.
• A spurious INEXACT flag leaked by integer rounding, removed.

Everything stays within the existing fpu_lib wrapper discipline — no raw host FP, no host-fenv-only tricks — so it remains compatible with a software-fenv / jittable softfloat path.

Validation

• riscv-arch-test (ACT4, Spike reference): F/D/I/M 101 -> 260/260.
• MPFR-oracle bare-metal harness (rvvm-hal examples/rmm-test): 43652/0 over the five OP-FP ops and the four FMA ops, each under both dynamic frm=RMM and the static ,rmm suffix, including subnormal and underflow-boundary ties.

Notes

The 11 commits are split one-fix-per-commit for review; No functional change outside src/cpu/riscv_fpu.{c,h} and src/util/fpu_lib.{c,h}.

[SolAstrius]

@purplesyringa please help us with your wisdom 🙏