Document optimistic multistream-select

[MarcoPolo]

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. fix: finish reading handshake on lazyConn close multiformats/go-multistream#115 - implementations should wait for the handshake to finish before closing the stream.
2. Ignore error if can't write back echoed protocol in negotiate multiformats/go-multistream#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: Lazy negotiation is unsound multiformats/go-multistream#20