Transition to poll_fn style backend traits

[plaidfinch]

Currently, the extra allocation and virtual call necessary for the boxed future returned by the backend traits leaves us about 50% slower on the microbenchmark against plain Tokio MPSC channels. Until just now, I thought this wasn't soluble without either proper async trait method support or GATs in Rust. However, this ignores the other remaining option: relinquish the design requirement that Transmit/Receive implementations be possible to write using async/await syntax.

If instead the traits are defined in terms of poll functions, similarly to how Sink and Stream are, we can define our own internal explicit futures that wrap an &mut Tx or &mut Rx and use these poll functions to provide the same interface. We could even provide extension traits TransmitExt/ReceiveExt to allow transmitters/receivers to be directly manipulated in async blocks. And all of this doesn't require any boxed future manipulations, which means it should compile away to essentially the same result as invoking the underlying transport directly.

[plaidfinch]

This change is interrelated with #76, because the support for batching/buffering requires additional structure in the definition of Transmit. The two changes could be implemented in either order, but they will overwrite some of the same code, and therefore should not be implemented simultaneously.

[plaidfinch]

It further occurs to me that Transmit should be equivalent to Sink. But, Receive is not quite equivalent to Stream since (a) it has an error type and (b) its item type is a parameter, not an associated type. Is there an exact dual to Sink in a common library?