Consolidate naming for async_scope algorithms

[lewissbaker]

There are a growing number of potential async-scope algorithms that we might want to provide.
However, the naming of these algorithms is somewhat inconsistent.

This issue tries to gather them all into one place and classify them with the hope that this will help us come up with a better naming scheme that is less-confusing for users.

• nest(src, scope) - lazily started, no heap-allocations, waits for underlying op to finish if cancelled, multi-shot if 'src' is multi-shot - multiple consumers each launch independent operations
• spawn(src, scope[, env]) - eagerly started, detaches immediately,
• spawn_future(src, scope[, env]) - eagerly started, returns a single-shot sender, cancelling returned sender detaches (after sending stop-request to 'src' op)
• split(src, scope[, env]) (see Change split algorithm to be an algorithm over an async-scope #263) - lazily started, returns a multi-shot sender that caches/shares result, detaches on cancel, cancels underlying op when last consumer detaches
• detach_on_cancel(src, scope) - lazily started, returns single-shot sender, detaches on cancel
• spawn_shared(src, scope[, env]) - eagerly started, returns multi-shot sender that caches/shares result, detaches on cancel, cancels underlying op when last consumer detaches

There is general consistency about naming with regards to eager operations - they are all prefixed with spawn.

There is less consistency with the lazy versions, however.

Perhaps we could consider renaming:

• detach_on_cancel -> nest_future
• split -> nest_shared

This would then have the suffixes consistent with spawn_future and spawn_shared, which have similar detach-on-cancel semantics and both return a single-shot/multi-shot versions.

Having said that, this loses a little bit the key semantic of "detachment" on cancellation.