Add specification for new (1.1.x) protocol

This is my current proposal for a new protocol, aimed for release with Ricochet 1.1.0. See #81. For easiest reading, click 'View' on the file and enjoy formatting.

The goals here are:

1. Improve software security with a more careful implementation, standardized serialization code, etc.
2. Undo bad decisions from the original protocol, especially those that would complicate future work
3. Write a *lot* of new code, hopefully better than old code

This proposal is pretty complicated, but it's mostly as an effect of being expandable and verbose. It is from-scratch and unrelated to any other messaging protocol, because they're either painful disasters, difficult to modify for this architecture, or both.

There is no attempt to be backwards compatible with the previous protocol, and the functionality defined so far is equivalent but somewhat improved. I also haven't addressed layered cryptography (#72) - that will happen later, when we have the resources to research and implement it properly.

This document doesn't explain the networking architecture in depth; as a separate project, I intend to write that document as a starting point for improving how we interact with hidden services. The implementation of this new protocol doesn't change those details so far.

Once approved, this will be very quickly followed by the implementation in several pieces, and then by exciting new features.
I should explain this logic more clearly.

The intent is that *message_id* will be probably unique for all unique messages *from the same client* and *within a relatively short period of time*.

If the connection dies with unacknowledged messages, we want to try sending those messages again when the connection comes back. That's very helpful for being robust against minor network interruptions.

It's possible that the messages were received, but acknowledgement wasn't. In that case, we don't want the same message to arrive twice. This is the case where it can be useful to compare *message_id* for messages from different connections (but still the same person).

So the logic is:

* When a message arrives, look for its *message_id* among the last few messages received from that person.
  * If a match is found, compare *message_text*. If it is identical, ignore the duplicate message, but still acknowledge it

* If the connection is lost when messages have been sent but not acknowledged, keep them ready to re-send
  * When the connection is established again, send those messages with the same *message_id*

The first *message_id* on a connection is randomized because this is the simplest way to avoid collisions on *message_id* if we made several new connections in a short time. It's incremented for future messages on that connection because there's no point in randomizing it every time.

Does that make more sense?