Document optimistic multistream-select

Also sometimes called lazy negotiation or lazy multistream-select.

In {Go,Rust} (unsure about others) we do an optimistic multistream-select when we know the peer supports a certain protocol. The dialer writes the multistream header, the application protocol id, and then application data at once without waiting for the peer to echo back the application protocol id. This lets us remove one round trip when creating a stream and it helps for the one stream per RPC use case.

However, afaict, we have not documented this or what pitfalls to be aware of. Three pitfalls come to mind:

1. https://github.com/multiformats/go-multistream/pull/115 - implementations should wait for the handshake to finish before closing the stream.
2. https://github.com/multiformats/go-multistream/pull/87 - related to the above, implementations may want to ignore handshake write errors so that applications can still read data from the stream.
3. Edge cases around application data being interpreted as multistream-select data: https://github.com/multiformats/go-multistream/issues/20

Start by reading the linked go-multistream PRs 115 and 87 and issue 20 to understand optimistic multistream-select and its interoperability pitfalls. Document when the optimization is appropriate, how handshake completion and write errors affect stream closing and reads, and how application data can be misinterpreted as negotiation data.