Allow splitting a Telnet Connection into a Reading and a Writing half

[Kilobyte22]

Often times, it is desirable to have a full-duplex connection. This (assuming sync IO) generally requires handling reading and writing in different threads. However, due to rusts ownership model, this is not possible without splitting the connections into two halves. Therefore i propose the following API changes:
The Telnet impl would get a new function fn split(self) -> (TelnetRead, TelnetWrite). TelnetRead would be a struct with the subset of functions on Telnet which perform reading and related operations (read, read_timeout, read_nonblocking) while TelnetWrite would implement the writing subset (write, negotiate, subnegotiate).

I think the best way to implement this would be to move the actual logic into the TelnetRead and TelnetWrite structs. The Telnet struct contains an inner TelnetRead as well as a TelnetWrite and proxys all function calls to the inner objects. Both TelnetRead and TelnetWrite need their own copy of the Socket for this. This would require Stream to have a way to create a copy of the socket, which in turn would have to implement Clone or similar (TcpStream has a try_clone()). Something else implementing Stream might also have a splitting function, instead of cloning. I therefore propose adding something along the lines of fn split(self) -> Result<(Write + Stream, Read + Stream), Error> to Stream, which can also be implemented using clone.

I am willing to do the implementation work myself, however i wanted to discuss this first, as to avoid unnecessary extra work. I am aware that this would probably be a breaking change.

EDIT: I also believe TelnetRead, TelnetWrite and by extension Stream would need a + Send constraint, so you can actually pass one of the halves to another thread

[SLMT]

Thanks for your proposal. I think your proposal looks great! You may start to do the implementation anytime.

Indeed, due to the ownership system of Rust, it is not easy to separate the reading and writing of a stream. So I agree that we may need to add fn split into the library. As you said, it looks like this proposal will change the API a lot, but I think these changes are acceptable.

You can use 0.2.0 as the version number.