[mplex, yamux] Streamline configuration API.

[romanb]

This is a proposal for streamlining the configuration APIs of libp2p-mplex and libp2p-yamux, i.e. to close #1531. I made the following choices:

• For all configuration options that exist for both multiplexers and have the same semantics, use the same names for the
  configuration.
• Rename yamux::Config to YamuxConfig for consistency with the majority of other protocols, e.g. MplexConfig, PingConfig, KademliaConfig, etc.
• Completely hide yamux APIs within libp2p-yamux. This is a trade-off. It allows to fully control the libp2p API and streamline it with other muxer APIs, consciously choosing e.g. which configuration options to make configurable in libp2p and which to fix to certain values (e.g. we currently always fix read_after_close which is not actually configurable for libp2p). It also means that new incompatible version bumps of yamux need not necessarily require analogous bumps for libp2p-yamux, as no yamux types are exposed. The cost is naturally some more duplication of configuration options in the API, as well as the need to update libp2p-yamux if yamux introduces new configuration options that libp2p-yamux wants to expose as well. Overall I think fully hiding yamux from the API, i.e. making it an implementation detail, is preferable.

[mxinden]

Completely hide yamux APIs within libp2p-yamux.

I am indifferent in regards to this change. It does add another layer of indirection and forces us to keep documentation in sync manually, e.g. for WindowUpdateMode. Either way, given that neither yamux nor libp2p-yamux change at a fast pace, I think this is manageable.

Thanks for doing the cleanup!

[romanb]

I am indifferent in regards to this change.

I'd just like to point out that as I see it there is only the choice between either hiding the yamux API to fully control the libp2p-yamux API and achieve better consistency with other libp2p APIs, or to close #1531 as a "won't fix", because it does not seem sensible to adjust yamux APIs so that they conform better to other libp2p muxer APIs, i.e. it is clearly up to libp2p to decide whether it wants to fully encapsulate and control the muxer APIs or whether it accepts exposing potentially very different-looking APIs through direct exposure of underlying libraries. The case in point that makes me think the approach proposed here is worth a try is the fact that there is already one yamux configuration option which libp2p-yamux does not actually allow to configure, namely read_after_close. Whether there will be more such cases remains to be seen, but giving the impression on the outside that all of the yamux configuration API is available in libp2p when it is not is at least slightly misleading.