MultiplexingStream should apply backpressure to individual channels

[AArnott]

To avoid a fast sender and slow receiver from plugging up the entire connection (when we're out of local buffers to receive for an individual channel), the MultiplexingStream should apply and respond to backpressure.

Design proposal

1. Offer and accept channel frames should include allowed window size.
2. Channel.Input should track how many bytes have been processed by the reader and send frames back to the remote party to inform them so they know when they can start transmitting.
   1. What is the minimum newly processed data size before a frame should be transmitted? For example if the reader only processes 3 bytes, we shouldn't send a frame back to the sender to let them know.
      1. One frame size processed is worth transmitting about.
         ii. When there is more than one frame to transfer and less than one frame of window remaining, consider waiting till more window space is available.
   2. What if the reader 'processes' 0 bytes but acknowledges all of them? Pipelines API allows this as a means to receive more data. Unless mxstream supports that too, it can result in deadlocks.
      1. The channel can send a special frame requesting the sender to transmit exactly one more frame. The Pipelines API will allow exactly one more Write call to complete, so this is safe. It will provide the receiver with the additional data they need. This process can repeat if the reader 'examines' the whole buffer again.
3. Channel.Output should track how much data was transmitted and compare to how much data has been processed by the remote party so that it does not flush data that would exceed the allowed window size.
4. Add tests for when window size is larger/smaller/exactly window size.
5. Set default window size to be some multiple of the frame size.
6. A default window size is communicated during the mxstream handshake for channels that are created and transmitted to even before acknowledgment is received.
   1. This default must be NO GREATER than the minimum allowed window size for any individual channel, since otherwise once the channel is accepted and its pipe is set up, it could still overflow with data transmitted from the channel's creator based on the previous, larger window size.
7. If a channel requests a window size that is less than the mxstream's default window size, quietly just raise the window size for the channel to match the default value.
8. How to detect window size when given an ExistingPipe? ❓
9. Make protocol more flexible for versions.