Introduce new per-thread CHERI state maintained by the kernel: struct
cheri_signal, which holds a partial CHERI context to restore when invoking
a signal handler.  Similar to signal delivery setting up the MIPS $pc and
$sp variables, it now also sets up $c0, $c11 (the stack capability), $idc,
and $pcc that execute the handler with ambient autority.  As we cannot
trust memory pointed to by $sp, as that variable is controlled by
sandboxed code, we only permit delivery to a handler if the signal will
use the alternative signal stack; otherwise, the process is terminated.
There may be other behaviors we can investigate here in the future, as for
compatibility purposes, it would be nice if libcheri (and other runtimes)
can avoid interfering with an application's own signal stack behaviour.

For now, a thread's cheri_signal state is initialised at process start in
the same way that the corresponding registers are, and they are propagated
across thread fork, but they cannot yet be set directly.  If this proves
desirable (this seems likely), we can add additional sysarch() calls to
get and set the block on a per-thread basis.

After the handler returns, the original (or perhaps modified) CHERI
register state for the thread is restored.  This makes signal delivered a
bit like object-capaniloty invoke, but is quite different in practice: no
trusted-stack entry is installed describing the preempted context, as this
is instead on the signal stack and includes the full register context, not
just saved $pc/$pcc/$idc.  While further signals can be taken in the
ambient signal-stack context, it is undesirable to invoke further objects
on the signal stack, as the kernel will be unable to make a useful
decision about where to place the next stack frame.  It is therefore
recommended that, as with a number of other complex activities, invocation
not be performed from the signal context: instead, this work should be
scheduled for a safer context.

With these changes, it is now possible for a userspace application to
catch and handle signals while in a sandbox, which may be required by
future work on garbage collectors, etc.  It also provides a
userspace-directed alternative to simply unwinding the trusted stack by a
layer when a signal occurs, which might include (in the future) delivering
signal information to the sandbox itself, or providing better "your
invocation failed" handling in the caller.
an
Install an alternative signal stack in /bin/cheritest so that signals can
be handled while sandboxed code is running.

With this change, the invoke_spin test now passes, as SIGALRM caused by
sandbox timeout is now caught by the test framework and used to provide a
controlled exit, rather than an uncontrolled one.