We need a mechanism to crash Trio with a given exception; how should it work?

There are a few places where we want to crash trio.run with a given exception. Meaning something like: cancel the main task, unwind everything, raise the given exception as the final result. This is needed for:

• KeyboardInterrupt (when it's not delivered directly to a task) (#733, #1537, etc.)
• Exceptions from "can't fail" functions like run_sync_soon and system tasks (which also want a way to avoid raising TrioInternalError – #1056)
• When a deadlock is detected (#1085)
• When pytest-trio's test timeout expires (https://github.com/python-trio/pytest-trio/issues/53)

It's not quite clear what the semantics should be though!

One option: when asked to "crash", we:

• cancel the main task, if it's still running (if not, that means we're already shutting down, so we can skip this step)
• save the "crash" exception in the Runner state somewhere
• on the way out of run, check if we have any saved exceptions, and if so, do... something with them. If main_task_outcome is a Value, it's easy, just raise a MultiError(saved_exceptions). If the main_task_outcome is an Error, I'm not sure what the best approach is. MultiError(saved_exceptions) with the main_task_outcome as __context__? That could be confusing since the exception stored in main_task_outcome might have only occurred after and as a result of a sequence like "crash" → cancel main task → something on the cancel path raises an exception. I guess the only alternatives though are (a) discarding the main task exception, (b) MultiError(saved_exceptions + [main_task_exception]). Not sure if either of those is actually better.

Note that we're already doing something kinda similar at the end of unrolled_run to handle ki_pending.

Start by reading the Runner state and the shutdown handling in run and unrolled_run, including the existing ki_pending logic. Trace how main_task_outcome and exceptions from system tasks are handled. A complete change would define the crash semantics for each listed case and cover the resulting exception behavior with tests.