Tracking issue for websockets

[museun]

This crate will be the basis for it: https://docs.rs/async-tungstenite/0.8.0/async_tungstenite/index.html

It only provides tokio, async_std and gio. It wouldn't take much work to support just async-io or async-net to avoid pulling in all of async-std

• Determine whether to just provide connectors, such as
  • async_std::ConnectorWs
  • async_std::ConnectorWss
    • async_io::ConnectorWs
    • async_io::ConnectorWss
  • tokio::ConnectorWs
  • tokio::ConnectorWss
• Determine the use of async-io vs async-net in this crate (async-net didn't exist when I implemented all of this)

Should just provide a Stream and possible Sink interface? Currently, we have a bespoke Encodable trait but with the soon-inclusion of Stream into std it may make sense promote that to the 'supported' interface for reading. Note: Sink is in futures_sink and won't be in std for a while

We can split this crate, internally, into a lower and higher versions. The higher module could be split into async and sync as well.

This would allow people to pick just what they want -- and allow me to reduce the boilerplate and increase the discoverability of APIs and platforms.

With reference to #197 I, actually, really dislike the AsyncRunner. It does too much in a too-hidden way. I think a simple Stream type which impls futures_stream::Stream and futures_sink::Sink should probably be provided.

The timeout/heartbeat/idle detection can be built ontop of that -- if users want these features then we can take a optional dep onto async-task internally to handle that in a less .. convoluted way.

update:
The Sink trait is too complex for any benefit

[museun]

This will be a semver breaking release, again.