Zicsr tests fail to compile for U-mode cores without F, V, or Zicntr

[karabambus]

Test name
rv32i/Zicsr/Zicsr-csrr{w,s,c,wi,si,ci}-00.S (12 tests, rv32i and rv64i)

Describe the bug
All 12 Zicsr tests fail to compile with #error no CSR known for testing on any core that has U-mode but no F, V, or Zicntr. The generator selects a test CSR at compile time via a preprocessor chain in csr_type.py and csri_type.py:

#if defined(F_SUPPORTED)         // fflags
#elif defined(V_SUPPORTED)       // vxsat
#elif !defined(U_SUPPORTED)      // mepc
#elif defined(ZICNTR_SUPPORTED)  // instret
#else
  #error no CSR known for testing

The chain does not handle a U-mode core without F, V, or Zicntr. cv32e20 (RV32IMC + U-mode, no F/V/Zicntr) hits #error on every test case across all 12 files.

Expected behavior
Zicsr tests should compile and run for any core implementing Zicsr. The Zicsr norm rules mandate coverage of instruction operands (rd, rs1, imm) only -- the choice of test CSR does not affect normative coverage.

Additional context

Fixes considered and gaps:

• mscratch: causes trap loop. The trap handler uses mscratch as a pointer to its register save area. Writing a random value to it makes the handler dereference a garbage address on the next trap.

• mepc: safe for M-mode tests. Only written on trap entry, which cannot occur during normal M-mode CSR instruction execution.

Proposed fix: extend the chain to fall back to mepc for M-mode cores when no unprivileged CSR is available, ordered so unprivileged options (F, V, Zicntr) are preferred before M-mode CSRs. Zicsr is an unprivileged extension and Zicntr CSRs can exist without M-mode, so Zicntr must come before mepc in the chain.

Gap: a core with Zicsr but no M-mode, no S-mode, no F, no V, and no Zicntr is a valid configuration the fix cannot handle. Such a core requires a per-core RVMODEL_ZICSR_TEST_CSR macro pointing to a suitable implementation-specific CSR.