Replace LP2PReceiver.ontransport with LP2PQuicTransportListener

[backkem]

This PR writes out the last option mentioned in #32. LP2PReciever.ontransport is removed in favor of a LP2PQuicTransportListener object. This allows a QuicTransport to be created/accepted by both the LP2PReceiver and LP2PRequest. It also replaces the EventHandler with a ReadableStream as mentioned in #30.

Do we find this to be an improvement overall? The new code examples look reasonable to me. The downsides I see are:

• LP2PQuicTransportListener is quite long.
• You have to know about the LP2PQuicTransport and LP2PQuicTransportListener constructors in addition to LP2PReceiver and LP2PRequest.
• There is a naming difference between LP2PReceiver and LP2PQuicTransportListener. However, that does reflect their different way of working.

One way to address these is to add shorthand helpers as existed in the original explainer, pseudo code example:

// Peer A
const listener = navigator.lp2p.listen( { /* ... */ } );

// Peer B
const transport = navigator.lp2p.connect( { /* ... */ } );

---

Preview | Diff

[anssiko]

This looks good.

I support the idea of shorthand helpers to minimize conceptual weight for common use cases. It is OK for more advanced use cases to require a more involved API. The common things should be easy, advanced things possible (that is, need to refer to API docs). If we can already identify those common code paths we will do web developers a service by providing helpers.