client: stream call_client_stream request body via channel

[connyay]

Previously call_client_stream concatenated every encoded envelope into a single BytesMut and handed it to full_body(), so the transport never saw the first byte until the entire iterator had been drained. Peak memory was O(total) and a slow- or large-yielding iterator buffered everything in process memory before any of it hit the wire.

Switch to the same channel-backed body pattern call_bidi_stream uses: a depth-32 mpsc channel feeds ChannelBody, the iterator drain pushes one envelope per item with natural backpressure on HTTP/2 flow control, and the response future is driven concurrently so frames flush as they're produced. Peak memory drops to roughly channel_depth * envelope_size.

The transport send is dispatched onto a separate task so its body is polled while we drain the iterator (a transport whose send() future contains the actual I/O would otherwise deadlock once the channel filled). On wasm32 there is no tokio runtime; spawn onto wasm-bindgen-futures' single-threaded executor instead. Either way, the response is bridged back via a oneshot so the awaitee is uniform across architectures.

The IntoIterator<Item = Req> public signature is unchanged, so codegen and existing callers are unaffected. A new regression test in tests/streaming installs a recording ClientTransport into the generated EchoServiceClient and asserts the body arrives as N frames for N messages instead of one concatenated frame; this fails on the previous buffered code (1 frame of 68 bytes) and passes on the new code.

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}