Implement Sink and Stream for WsClient

[FSMaxB]

This implements Sink and Stream for WsClient.

Why is this useful?

If you use tokio-tungstenite as your websocket client, you will usually have a tokio-tungstenite::WebSocketStream to work with, which exclusively uses the Sink and Stream traits for sending and receiving messages. Implementing Sink and Stream for WsClient as well allows for writing code that works with both the real tokio-tungstenite::WebSocketStream and WsClient by relying only on the Sink and Stream traits in the implementation, especially if you combine it with #903 which provides conversions between warp::ws::Message and tungstenite::protocol::Message.

Why not use tokio::sync::mpsc::unbounded_channel

Initially I tried to implement this using the tokio mpsc channels that WsClient was using, but found it to be impossible.
Implementing Stream isn't an issue because of the Stream implementation provided in tokio-stream and because tokio::sync::mpsc::UnboundedReceiver has a poll_recv method exactly for that purpose.
Implementing Sink however doesn't work because there is no way that poll_flush or poll_close can notify a task to be polled again.

Therefore this PR switches the channel implementation from tokio to futures, since futues::channel::mpsc::UnboundedSender and UnboundedReceiver already implement Sink and Stream and the implementation on WsClient then only need to proxy their calls to the underlying channel.

[FSMaxB]

I'm going to rebase this shortly since merging #906 broke this pull request. This PR now also needs to add futures-channel on top of the futures-util dependency currently on master.

[jxs]

Hi, and sorry for the delay! Makes sense, thanks!