Add backpressure to Channel receivers

[EpicEric]

Fixes #392.

Simply put, this changes its UnboundedReceiver from
unbounded_channel with a Receiver from channel(...), with a
configurable value in channel_buffer_size of 100. This means that, for
each channel that's created, it can hold up to 100 Msg objects, which
are at most as big as the window size plus metadata/indirection
pointers.

This is enough to force messages to be read from the underlying
TcpStream only as quickly as the server/client is able to handle them.
This has been tested with the example given in #392, including a
modification to slowly read into a non-expanding buffer, and appears to
fix the issue that's been pointed out.

Some other considerations:

• It is still possible to cause memory to explode by opening multiple
  channels, although that might be intentional on the user's part. In
  this case, it's up to the user to handle when channels get created or
  not.
• The limited buffering also means that control Msgs (eg. Eof) will
  also be delayed by the transport layer backpressure, although this
  might be expected by the SSH standard. Reading through RFC 4254, I
  couldn't find any mention of non-Data/ExtendedData messages having
  to be dealt differently, but I don't think it's even possible to do so
  over TCP. If this assumption is wrong, this might require a separate
  mpsc::unbounded_channel just for control messages.

BREAKING CHANGES:

• This removes fn send_channel_msg, which doesn't seem
  to be used anywhere in this library, but is part of the publicly
  exposed API nonetheless.
• This adds the configuration value channel_buffer_size to both
  servers and clients that allows setting how big the buffer size should
  be.

[Eugeny]

Thank you!