This is for debugging purposes so that we have a test case that unwinds to `lucet_context_backstop`.

This causes several of the existing test cases to fail, but if you want one that is solely focused
on this behavior, run:

```
cargo test -p lucet-runtime --test host unwind
```

... when guest code has correct .eh_frame information, anyway.

this currently results in the personality function being called if you
run the lucet-runtime hostcall tests under gdb with the following
commands
```
set args unwind --test-threads=1 --nocapture
b rust_panic
r
```
then, when the breakpoint (`rust_panic`) is hit, replace the first
return into guest code with a return to `lucet_context_backstop`:
```
`#      v-- this is the address of lucet_context_backstop`
printf '\x61\x7f\xa0\x56\x55\x55\x00\x00' \
  | dd `# because gdb doesnt like "set *(long long*)0xaddr = value ` \
    `#         v--- just finding the pid of the test debugee ` \
    of=/proc/$(ps -ef | grep lucet | grep unwind | cut -d' ' -f2)/mem \
    `#           v-- this is where the first guest return address is `\
    `#           v   ..for me anyway. replaces 0x00007ffff6878685` \
    `#           v   for "guest_func___original_main". `\
    bs=1 seek=$((0x7ffff6872fa8)) \
    `# dd would try to truncate guest memory by default. do not do this. `\
    conv=notrunc
```
(if you can figure out how to do this standalone in gdb, i'm all ears)

at this point, continuing in gdb to allow the panic mechanism to run
should ... call into the provided personality function!

Also includes a not-quite-working personality function for the backstop that fails because the
system unwinder doesn't want us to be able to set rdi, even though that's explicitly one of the
registers listed as being supported for landing pad passing purposes.

This means backtraces and panics now work across the host/guest stack boundary

This test works with the nightly-only `#[unwind(allowed)]` attribute, which we'll hopefully be able
to help move along.

The current state of the repo is such that only the `fault_unwind` test is currently relevant:

```
cargo test -p lucet-runtime --test host fault_unwind -- --nocapture
```

Currently stuck figuring out how to set up the stack properly in order to return into the function
that panics. If I pad the stack with a zero word in order to keep it 16-byte aligned, the unwinding
runtime interprets that zero as a return address and fails. If I don't add the padding, later
instructions fault because of unaligned arguments.

We probably need to add a shim that uses `.cfi` directives in order to make the unwinding runtime
skip over the padding.

- adds a `catch_unwind` around each hostcall to make sure we decrement `hostcall_count` when
unwinding
- handles `State::Yielded` instances by setting a pending termination flag, and then resuming

This state already had the context information we needed to initiate unwinding, so we didn't need to
add an extra field on our `Context`, or preemptively overwrite the guest context in the signal handler

the struct at rbp changed between first authorship and today, to fix a bug where lucet instances were accidentally tied to their starting thread

when forced unwinding was first envisioned, guests did not run at all
from the point they faulted. this mean that the fault address would be a
simple `guest_ctx.get_ip()` away. in the mean time, the Lucet signal
handler learning how to be crossplatform broke this assumption: it now
works by *overwriting* the guest's instruction pointer, swapping to the
guest, and letting a function run. consequently, the guest instruction
pointer is replaced and when a guest unwind is instigated after a guest
faults, the return address before `initiate_unwind` (or `unwind_stub`,
if present) will no longer be correct. libgcc_s will then fail to locate
an FDE to describe the call frame above runtime-added unwind machinery,
fail to unwind, and SIGABRT.

the solution is quite simple: since the rip-accessing code is already
handling a guest fault, we know the original faulting guest `rip` is
preserved in the fault's `details`. insted of `guest_ctx.get_ip()`, get
the address from `details.rip_addr`.

…ll be upstream