Support batching backends

[plaidfinch]

More efficient backends may wish to batch messages transparently. This can be enabled by adding a flush async method to Transmitter with a default implementation of doing nothing. Invoking recv-requiring methods on Chan will implicitly call flush first (or concurrently?) to ensure communication dependency ordering is preserved. It's also necessary to call flush implicitly before split, since the concurrent receiving half might be waiting for a response to something already sent. A new method on Chan should be added which manually invokes flush, too. Finally, close should be made an async function, and it should call flush prior to dropping the channel, but only if there are no other references to the Arc awaiting the Tx—i.e., the transmitter should be automatically flushed on close only when the session is not going to be resumed by an outer context.

For non-batching backends, no code changes are necessary. Uses of close will need to be changed to be async.

The primary use case for this would be in the serde backend, which could now support a BufferedSender/BufferedReceiver pair, parametrized by all the parameters of the underlying transport for the non-buffering variety, as well as a maximum buffer size (which, if exceeded, triggers an automatic flush).