Implement native unwind behaviour for coroutine cancellation

[lewissbaker]

Coroutines now automatically unwind themselves if an awaited
operation completes with 'done'. Note that this 'unwind' process
is not catchable.

This signal will be transported up the stack until it hits a consumer
that does handle the 'done' signal. This typically means wrapping
the task<T> in a sender-algorithm that translates the done-signal
into some other signal that a coroutine can then handle.
eg. as an error/exception or as a value.

This means we don't have to unwrap std::optional values every
time we co_await something.

This relies on coroutine promise_types implementing a new
unhandled_done() method, similar to unhandled_exception(),
that handles the 'done' signal for that particular coroutine type.

The task type simply forwards the signal on to the awaiting
coroutine's promise.unhandled_done() method. This recursion
is terminated by the connect_awaitable() implementation which
implements unhandled_done() to forward on to the receiver's
set_done() implementation.

[ericniebler]

This is rad.

[ericniebler]

Did we ever consciously choose camelCase for variables? My preference is for snake_case. Obviously not a problem you should be solving here, though.

[lewissbaker]

I have always been writing camelCase for non-public variable names.
Public data-members that form part of the interface are still snake_case.
Although I've noticed others have been using snake_case variable names, so we're not consistent.

[kirkshoop]

This makes me smile!

[ericniebler]

@GorNishanov should get a load of this.

[ispeters]

This is beautiful!

[ericniebler]

There are a lot of senders in unifex that don't have a sends_done static member. It would be work looking into why only MSVC is complaining, though. I'm guessing there is some unnecessary instantiation happening with MSVC due to return type computations happening too eagerly, or something. It might be unavoidable.