define how to handle `/` in component values when represented as a string

When a component value has a / in it, it becomes hard to round-trip a multiaddr from bytes to a string and back again, since it's unclear where the value ends and the next protocol component starts.

A growing list of where this is relevant:

• /http-path has solved this problem by url-encoding the value (see https://github.com/multiformats/multiaddr/pull/164).
• /unix needs a similar solution: https://github.com/multiformats/multiaddr/pull/174
• Potentially adding libp2p protocols to multiaddrs has come up in https://github.com/multiformats/multicodec/pull/380 (yes, wrong repo) which are full of / characters.
• In the scope of https://github.com/multiformats/multiaddr/issues/155 - where we might parse a multiaddr from a string that contains protocol components we don't understand, for example /ip4/123.123.123.123/my-new-protocol/herp/derp. The unknown protocol would be easier to ignore if it was encountered as /ip4/123.123.123.123/my-new-protocol/herp%2Fderp (though obviously it can't be round-tripped as we don't know what the protocol code for my-new-protocol is).

Perhaps it's time to specify how to handle this character properly?

Represent it in the string version of a multiaddr as %2F?

Review the existing /http-path URL-encoding solution, the proposed /unix solution, and the unknown-protocol case described in issue 155. Define a consistent representation for slashes in component values and specify the round-trip behavior, including how unknown protocols are handled.