RFC: Split sync and async crates

[1tgr]

I'd like to get some opinions on splitting the websocket-lite crate into two halves:

• The existing websocket-lite to be trimmed to only the async functions
• A new websocket-lite-sync crate with only the synchronous functions

On #230, @Gelbpunkt requested to remove the synchronous functions but I said they were useful: non-futures-based code is easier to optimise, and works fine provided you can dedicate a thread to a connection.

On #204, @jjl suggested that we could remove the tokio dependencies for apps that only use the synchronous code.

I propose that the websocket-lite and websocket-lite-sync crates have an identical API: for example, both crates expose a method ClientBuilder::connect, instead of separate connect and async_connect methods.

The websocket-codec crate gains a tokio feature, which causes it to impl the Encoder and Decoder traits from tokio_util. The crate gets its own Encoder and Decoder traits, regardless of the tokio feature.

Rather than copying and pasting the source code into two crates, I was considering using the im and im-rc crates' trick to compile two crates from one source tree.

[1tgr]

As described, this change causes disruption to current async and synchronous users of websocket-lite:

• For an async user, the crate name stays the same, but we rename async_connect to connect
• A synchronous user sees compiler errors until they reference the new crate, then their current code compiles

Alternatively, websocket-lite could contain the synchronous code, and we could have a new tokio-websocket-lite for the async code:

• An async user sees compiler errors until they reference the new crate, then they have to remove the _async suffix from method calls
• A synchronous user sees no changes, although tokio, futures_util and other async crates are no longer needed