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.
Does it make sense to have channel closing happen on the channels themselves? Or would this make more sense on the control channel to match opening?

I suppose having it here does make some things like file transfer less convoluted, as one can simply queue a close of the transfer channel after the transfer of the data completes. Is that the intention?