[cheriot,rtl] Decide whether Zcmp can be supported in CHERIoT mode

#2475 makes the Zcmp encodings (cm.push, cm.pop, cm.popret(z), cm.mvsa01, cm.mva01s) illegal when cheriot_enable_i == IbexMuBiOn, because their expansions are incompatible with CHERIoT: cm_sp_addi() expands to addi x2, x2, imm, which writes a NULL capability and so destroys csp's tag and bounds; the register saves/restores use sw/lw, so cra's backward sentry is lost and the jalr x0, 0(x1) from cm_ret_ra() then takes a tag violation.

Trapping is the safe interim behaviour, but it means the opentitan config carries Zcmp hardware that is unusable in CHERIoT mode. The open question is whether to support Zcmp properly or declare it permanently incompatible.

The blocker for supporting it is the stack stride: Zcmp adjusts sp by 4 bytes per register, while capabilities need 8. The CHERIoT spec says nothing about Zcmp; CHERI-RISC-V declares it incompatible and defines its own unratified variant.

To decide:

• whether an 8-byte-stride CHERIoT variant is worth defining, and whether it should follow the CHERI-RISC-V proposal
• if not, whether Zcmp should be disallowed at elaboration time for BaseIsaRV32IorCHERIoT rather than trapped at runtime

@SamuelRiedel has a copy of the RTL using an 8-byte stack element. Context: https://github.com/lowRISC/ibex/pull/2475#discussion_r3802164766