[Morello] Work around RRLEN/RRMASK ISA quirk

For any representable length of the form (1 << 12) - 1) << (E + 3), i.e.
the largest representable length for an exponent E, RRLEN and RRMASK as
defined in Morello will incorrectly round the length up to the next
representable one. On the surface this might not be an issue, as one
might imagine it just results in a bit of redundant padding in edge
cases, but it is in fact problematic for software written against the
generic CHERI C interfaces. For example, a common way to assert that a
length is representable is cheri_representable_length(x) == x, which is
used in various places in CheriBSD, but this fails in the case that x is
one of the special values. In particular, this has been seen to happen
in the CheriBSD kernel's ELF image activator, since we round and align
the start and end addresses for the mapped region to be representable
and later assert this has been done, but very occasionally executables
are produced that trip this up and panic the kernel. One could go add a
workaround to every piece of software that requires the intrinsics to be
exact, but this quickly becomes tedious and may not catch all such
cases, leaving latent hard-to-trigger bugs on just Morello.

Instead, make the Morello implementation of the intrinsics conform to
the CHERI contract by expanding them to a multi-instruction sequence
that detects potentially-problematic cases and fixes them to be what
they should be. For efficiency, however, we leave DYNAMIC_STACKALLOC as
padded more than needed; note that we already have a second SCBNDS for
this case that takes the original unpadded length and so we will still
get the tighter bounds on the capability, just a bit of padding after
the top. The inexact instructions are also made available via new
Morello-specific __builtin_morello_*_inexact intrinsics.
28 jobs for !199 with rrlen-rrmask-bug-intrinsic-workaround in 297 minutes and 24 seconds (queued for 7 seconds)
merge request