v2? revisit RV C encodings?

[nwf]

Because we're RV32E, there are a fair few defined encodings that don't mean anything to us. Because RV C is... mm, let's say prone to creative reuse of their instruction "formats", this is somewhat trickier to actually count than one might like. Giving it a stab, tho', I think we have 1024 values from each of c.addi, c.li, c.lui, c.slli, c.fldsp (our c.clcsp), c.lwsp, c.flwsp, the combination of c.jr and c.mv, the combination of c.jalr and c.add, c.fsdsp (our c.cscsp), c.swsp, and c.fswsp, for a total of 12 1024-instruction blocks.

The RISC-V standard has backed away from their "no standard will ever use these encodings" stance (as of the 20190608 edition); the current draft standard says:

The previous draft of this chapter made all encodings using the x16-x31 registers available as
custom. This version takes a more conservative approach, making these reserved so that they
can be allocated between custom space or new standard encodings at a later date

It might be nice to use that space to introduce some compressed capability register-register operations that we use frequently. If we restrict to the 8 registers accessible to most compressed instructions, each will consume 64 values. We might also be able to squeeze in a compressed fused branch on tag unset, which could be useful for validity checks especially within the TCB, where the displacements are small.