implement a new multiaddress API

[marten-seemann]

Problems with the current API

Major problems:

• When receiving a multiaddress (e.g. from an address record in the DHT), we immediately try to parse it. If parsing fails, that multiaddress is discarded. Parsing fails if the multiaddress contains any unknown components: if a node hasn’t been updated to understand WebTransport addresses, it won’t be able to parse a WebTransport multiaddress, and won’t be able to forward it to other (WebTransport-enabled) nodes.

Related: multiformats/multiaddr#155

Minor problems:

• Multiaddr is an interface, and therefore (almost always) allocated on the heap. This creates a lot of GC pressure.
• Methods are split between packet-level functions (e.g. SplitLast) and methods on the interface (e.g. ValueForProtocol). There’s no (apparent) logic behind this, making use of the API confusing
• The methods weren’t designed with allocations in mind. One of them (especially Protocols) is the major source of allocations in a Kubo node

Tasks

• refactor!: make the API harder to misuse #261
• refactor: keep same api as v0.14.0 for SplitFirst/SplitLast #271
• refactor: Backwards compatible Encapsulate/Decapsulate/Join #272
• feat: Add Multiaddr.AppendComponent #273
• refactor: remove .Empty #274
• Simple fuzz test for v0.14 <-> v0.15 interoperability #270
• Faster megular expressions #265
• feat(x/meg): Support capturing components #269
• Megular Expressions #263

[MarcoPolo]

Another annoyance I ran into: Component doesn't implement the Multiaddr interface. So if you collect a bunch into a slice: []Components there's no way to join them all. I'm not sure if we even need the component in the new API, just wanted to mention it as another pain point.