Extracting this idea from #147, because that's a monster thread and this seems worth discussing separately.

Idea: a "service nursery" is one where the background tasks are "services" that don't do anything on their own, but provide some service to the main task. Therefore:

• background tasks are automatically cancelled when the nursery block exits
• before the nursery block exits, background tasks are automatically shielded from cancellation (and maybe KeyboardInterrupt?)
• mayyybe there's some special handling of exception propagation? if in the future we switch to always wrapping nursery exceptions in a multi-error-equivalent (MultiError v2 #611), AND multi-errors remain awkward and folks want to avoid them, then we could potentially do that with a service nursery by deeming that background tasks should never fail, so if they do then you get a special BackgroundServiceFailed error or something, and that way the main task body exception doesn't need to be wrapped in a multi-error? Dunno, this seems dubious to me.

Examples that fit this pattern:

• Trio's "system" nursery
• The background nursery that trio-websocket creates for each connection, or any other protocol that requires some background task to drive the socket
• The nursery fixture in pytest-trio
• Independently suggested by @matham at https://gitter.im/python-trio/general?at=5ebceeaf2cf0da0ad90004d4

Straw man implementation: #147 (comment)

Questions:

• Are those semantics right?
• Should the special "service-ness" flag be attached to the nursery, or to individual tasks?
• open_nursery(service=True) or open_service_nursery()?
• control-C handling? (see also Rethink KeyboardInterrupt protection APIs #733)