When Using a Proactor Allow Async Transport Calls Where Supported

[iancooper]

Is your feature request related to a problem? Please describe.
Brighter supports two models for concurrency: Reactor and Proactor. Both are single-threaded message pumps, but the Proactor uses asynchronous I/O. Theoretically the Reactor has better performance and the Proactor has better throughput.

In V9, the Proactor only assumes that user-defined code, in handlers or transformers will use asynchronous I/O, not any transports.

Transports are mixed in their support for sync and async APIs, some support both, some one or the other.

Describe the solution you'd like
In V10, have the Proactor assume that we have an asynchronous transport, not a synchronous one. Where the transport is natively async this will result in better throughput. Where the transport is not asynchronous, our synchronization context will prevent deadlocks.

This will require the addition of asychronous versions of IAmAChannel, IAmAMessageConsumer, and IAmAChannelFactory and their implementations.

Describe alternatives you've considered
We could continue to use a tactic of blocking on asynchronous transports to force them to be synchronous. This is less risky for us, due to our usage of a single-threaded pump that processes messages sequentially. But, this doesn't allow users who have chosen the model

Additional context
As these changes would be breaking, we need to make the choice to make them with V10, otherwise we will end up deferring them again to V11. We may also have context that most people believe that our transport calls are asynchronous in V9, when they use the isAsync flag on their declaration.