Rethink KeyboardInterrupt protection APIs

Sometime before 1.0, we should go through the KeyboardInterrupt protection APIs and think them through again.

There seem to be a limited number of patterns: decorating functions/methods that should always have KI protection enabled; setting the default protection in a new task (can be overridden if the function has a preference); temporarily disabling and then reverting to what it was before (especially, reverting inside a call to outcome.capture or acapture). Some of these are kind of awkward with the current API, or impossible (in some places I think we do disable/enable, rather than disable/revert-to-previous-state).

It would be nice to fix #550. This might be doable on 3.7+ by exploiting the atomicity of Context.run?

We'll also want to look again at the issues around atomicity when exiting context managers, I guess.

Should tasks inherit their default KI protection state from the parent nursery?

Start by reviewing Trio's current KeyboardInterrupt protection APIs and the patterns described in the issue. Read #550 and investigate the Context.run atomicity and context-manager exit concerns mentioned here. Done means agreeing on a coherent API design, including whether tasks inherit protection state from their parent nursery, with the related behaviors and edge cases resolved.