Complete stream write `ChannelFuture` on the actual write of a Muxer frame

The issue closely relates to #282

The problem:

When writing anything to a stream [child] Channel there is an associated ChannelFuture (either passed to or returned from the corresponding write() method).
That ChannelFuture should be completed when the associated message buffer is flushed to the wire. In other words when the associated muxer frame(s) write operation is completed. In yet other words when any buffer(s) associated with the message are released.

That allows various backpressure mechanisms to function correctly on the client side

Currently a stream write ChannelFuture is completed earlier here: https://github.com/libp2p/jvm-libp2p/blob/0981ec69761a469052aea388b452cb22bf65b9cb/libp2p/src/main/kotlin/io/libp2p/etc/util/netty/mux/MuxChannel.kt#L47
So it happens effectively right upon a stream Channel.flush() call. Thus even when the client code is respecting backpressure, i.e. writes the next chunk of data (e.g. writes the next Ethereum block in a batch) only after the previous write was completed, it could still overflow write buffers.

E.g. for the mplex muxer internal Netty write buffers are filled up if the remote reader is slower than local writer
E.g. for the yamux muxer it's internal stream write buffer is filled up

Start with libp2p/src/main/kotlin/io/libp2p/etc/util/netty/mux/MuxChannel.kt at line 47 and review the related behavior in issue #282. Trace how stream writes become muxer frames in the mplex and yamux paths, then verify that the stream ChannelFuture completes only after the frame write finishes and its buffers are released, preserving client-side backpressure.