Make Gateway and GatewayHandle generic over futures_util::Stream and Sink types

[bitfl0wer]

Currently, Chorus relies on tokio_tungstenite and its WebSocketStream. This blocks Chorus from being compiled for wasm32-unknown-unknown, because tokio_tungstenite, in this context, uses a MaybeTlsStream (which uses either openssl/nativetls or rustls, all of which are not compatible with this compilation target) and tokios net feature as a dependency (also unavailable for wasm32-unknown).

A possible solution here would be to use web_sys::WebSocket, which leverages Web APIs to have your browser (or whatever executor you have) handle the TLS/SSL stuff for us. This is, as far as I can tell, the only/current best way to use TLS Websockets for this compilation target. To do this, we'd have to do what the title says and make both Gateway and GatewayHandle and their websocket_send and websocket_receive fields generic over the Stream and Sink types provided by futures_util. This way, we can feature-lock wasm-compatibility, we do not have to replace our existing reliance on tokio-tungstenite and we do not have to change the control flow in gateway.rs in major ways.

[bitfl0wer]

Ideally, these abstractions/adapters would be written in a way which requires the minimum amount of conditional compiling flags/macro invocations.

Also, huge thanks to @hw0lff for aiding me through the entire way of figuring out what exactly caused the dependency inclusions which made chorus not compile for wasm32-unknown. Likely would have rage-quit if it weren't for his help :)