Print a failing schedule even during double panics

[jamesbornholt]

Double panics are a common problem in concurrent Rust code. For example,
a thread might panic while holding a lock, and then need to acquire that
lock again during stack unwinding, but the lock is already poisoned. In
these cases, Shuttle currently can't print the schedule that led to the
original panic, because the double panic aborts the process before our
catch_unwind has a chance to run.

This change adds a new panic hook that gets a chance to run before the
double panic happens. We use this hook to print the schedule, so that
even if we double panic in future at least the user gets some output
they can use to reproduce the problem. There's some trickiness here
(outlined in a module comment for failure.rs) around running different
panic handlers at different times, which makes the code a little more
complex than I would have hoped, but it gets the job done.

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[jamesbornholt]

Can we grab the schedule generated by the test, and add another (also ignored) test that replays it? Just to make sure, for instance, that the printed schedule is really complete?

The schedule actually won't be complete in this double panic scenario, as it'll miss whatever steps were taken during unwinding. I don't think there's a good way to fix that; we'd have to intercept the second panic somehow. Instead, what happens is that the replay successfully makes it to the first panic, which it reproduces, and then panics again because the schedule ends early. Same double-panic effect, just that the second panic is different.