[rs] integrate wrpc-transport-next

[rvolosatovs]

The transport abstraction has been reworked in #81, we should:

• migrate wit-bindgen-wrpc to the new transport API
• replace wrpc-transport by wrpc-transport-next (the end result is that wrpc-transport-next is renamed to wrpc-transport)
• deprecate wrpc-types crate

[jacobvm04]

Will creating traits along the lines of Encode and Receive in wrpc-transport-legacy be a part of this? Or would the approach those defined independently of wrpc-transport in wit-bindgen-wrpc itself like how runtime-wasmtime currently contains ValEncoder and read_value on it's own?

[rvolosatovs]

Will creating traits along the lines of Encode and Receive in wrpc-transport-legacy be a part of this? Or would the approach those defined independently of wrpc-transport in wit-bindgen-wrpc itself like how runtime-wasmtime currently contains ValEncoder and read_value on it's own?

I'd prefer the latter, basically we should be able to adapt runtime-wasmtime directly in most places. I think wit-bindgen-wrpc should "inline" the encoding and reading the values from streams similarly to what's done in https://github.com/wrpc/wrpc/blob/01a536b18c8522469a33cb72a2d5f702585a27ee/crates/wit-bindgen-go/src/interface.rs#L58-L1295 (note, that Go impl is out-of-sync with latest spec)
It's mostly just using functionality I've moved to https://docs.rs/wasm-tokio/latest/wasm_tokio/

We may want to generate T::encoder() -> impl tokio_util::codec::Encoder<T> API, which would provide ways to encode in either blocking or non-blocking manner (addressing #25), I still have not fleshed that out, but if you're interested in that approach, please go ahead.
I feel like inlining everything for now would be the simplest and quickest to implement

On a side note, we may want to eventually recreate the "dynamic" API like the one that existed before in wrpc-transport, but I don't have a use case for it just yet