Make PlatformRef::connect_* instantaneously return

[tomaka]

Close #1249

When it comes to TCP connections, the connection process follows the three way handshake. Once finished, we are now "connected" to the remote and can exchange messages. The same exists for WebSocket, where the server sends back an HTTP response signalling that we're now "connected".

However, when it comes to connections such as QUIC or WebRTC, it's less clear what "connected" means. QUIC supports 0-RTT connections, meaning that you're "instantaneously" connected. Similarly, WebRTC only actually does things once you try opening a channel, and it's not clear when you're actually "connected" or not.

Because of this, the word "connected" is a bit blurry.
In #1200, I've realized that we don't actually care whether we're "connected". Libp2p requires an extra handshake (Noise and maybe Yamux) anyway, and I don't see any advantage in differentiating the moment when the TCP handshake has finished and when the libp2p handshake has finished.
For this reason, in #1200, the concept of "pending connections" is gone. Instead, connections are instantaneously "connected", or, more precisely, there's no concept of "connected" anymore. There are only connections before their (libp2p) handshake and connections after their (libp2p) handshake.

#1200, however, introduced two issues:

• In case of WebRTC connections, it's not possible to know the local TLS certificate synchronously. The browser's function that generates a certificate is asynchronous (why? no idea, and at this point my main hypothesis is that people who design these things try to be as annoying as possible)
• Timeouts for pending connections (the TCP handshake) weren't working anymore.

While the second point could be solved with more code in the light-base library, I've instead decided to solve both by propagating the removal of the concept of "connected" to the PlatformRef trait.

---

cc @lexnv @skunert

What that means, pragmatically speaking, is:

• PlatformRef::connect_stream and connect_multistream must now return as soon as possible. They're still returning futures, but it's done for API reasons. These futures must not wait for the connection to be established or something.
• WithBuffers (the helper to help implement PlatformRef) now stores a Future<Output = Socket> instead of just a Socket.

So in order to update after this change, you should now return a WithBuffer<Future<Output = Socket>> from PlatformRef::connect_*, instead of a Future<Output = WithBuffer<Socket>>.
See the changes to default.rs for an illustration.

This change made it possible to significantly simplify the WebRTC browser implementation, as at the moment we open a hacky preliminary substream just to detect when we reach the remote.