How should fail_at & fail_after handle MultiErrors?

Suppose that something like MultiError([KeyError(), Cancelled()]) arrives at a with fail_after(...). Right now the Cancelled is absorbed, and then the KeyError continues propagating, because fail_after only raises TooSlowError if the block exits without any exception.

An alternative that might make more sense is to use a MultiError.catch to replace each Cancelled with a TooSlowError. The tricky bit is that right now, the abstraction boundaries don't really give fail_after a way to do this -- the MultiError.catch is hidden inside the cancel scope.

One option would be to move this functionality into open_cancel_scope itself. Another would be to make the Cancelled._scope attribute public, allowing an implementation like:

@contextmanager
def fail_at(deadline):
    with move_on_at(deadline) as scope:
        def handler(exc):
            if isinstance(exc, Cancelled) and exc.scope is scope:
                new_exc = TooSlowError()
                new_exc.__cause__ = exc
                return new_exc
            return exc
        with MultiError.catch(handler):
            yield scope

(The other advantage of this is that it would preserve the traceback of the Cancelled error, which currently gets lost. This is useful to see what operation froze.)

Start with fail_at, fail_after, open_cancel_scope, and MultiError.catch, then trace how Cancelled is absorbed and how scope ownership is represented. Resolve the intended handling for mixed MultiErrors, including whether Cancelled becomes TooSlowError and whether its traceback is preserved; add coverage for MultiError([KeyError(), Cancelled()]) once the behavior is agreed.