Cancelled AsyncResources eat exceptions

This is an especially surprising special case of #455.

This code:

with trio.move_on_after(1):
    async with any_asyncresource:
        try:
            await trio.sleep_forever()
        finally:
            raise ValueError

will swallow the ValueError, because it gets stuck as the __context__ of the Cancelled exception raised in any_asyncresource.aclose. And aclose here is basically required to raise Cancelled, because Trio rules require it to be a checkpoint.

This showed up in #1555, with trio.Process standing in for "any_asyncresource".

This kind of thing keeps showing up for me and it's extremely confusing to track down. I know the party line is "who knows if someone was going to handle that exception that got stuck as the Cancelled __context__, we shouldn't reraise it when we swallow the Cancelled". But I think sometimes raising an exception that the user thought was handled is a much better failure mode than sometimes silently swallowing an exception that no one tried to handle at all.

Start by reproducing the move_on_after example and inspect how cancellation, context, and asyncresource.aclose interact, including the trio.Process case from #1555. The issue names no file or test path; done requires an agreed behavior that avoids silently losing the ValueError while preserving the required cancellation checkpoint.