Add alternative multiselect proposal

[bigs]

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)

[bigs]

Jumped the gun with this, we'll put this up for discussion early next week.