Add alternative multiselect proposal

Potential successor for #95. Initial work by @raulk and @marten-seemann. Surfacing it here to start a discussion.

Goal

Achieve enough consensus to start more serious prototyping by next Wednesday, October 30.

Needs

[ ] @marten-seemann review
[ ] @Stebalien review
[ ] @yusefnapora review
[ ] @bigs review

Concerns

I'll let @Stebalien speak for himself, but in our conversation he mentioned that, while he's interested in this iteration, he'd like for multiselect to remain as composable as is possible. While having a compact, prefix-analyzable binary format like that described in #95 is nice, switching to protobuf does make life easier for development and wouldn't sacrifice too much. He's a bit worried that this represents an over simplification

Notes & Thoughts

Dynamic IDs: @Stebalien pointed out that his proposal is in agreement with the "receiver chooses the dynamic ID" approach, which is great. His proposal would require a slight change to be useful for the packet case, however. We'd need to add the ability to have a sender initiate with multiselect/string, for example, and then have a receiver reply with multiselect/dynamic, mentioning the same protocol string the sender sent and then assigning it a dynamic ID.
Payloads: Pretty much every message could be extended to have an optional payload, making it more packet-orientation friendly.
Parsing: Protobufs make parsing easier, but prefix inspection more difficult. I've already written a simple tokenizer for reading varints and varint delimited strings/bytestrings, so this shouldn't be an issue. For that reason, it may be nice to use a more compact binary format as described in the original proposal.

Cole's Conclusion

I think we could pick up #95 and modify it with some of the revelations from this iteration. In particular:

Keep the compact binary format.
Adopt the new negotiation flow by adapting messages like multiselect/string and multiselect/dyanmic to match the Offer and Use flow.
Optional payloads on most messages.
Reject messages are necessary:
- Reject protocol (referencing dynamic ID or string)
- Reject transport (prefer another transport)

libp2p / specs