Private messaging architecture

> See #4 for info on why this is in Git

## Off-chain / on-chain private sequenced transfer coordination


This gen2 architecture provides an extension over the first generation, to solve two interconnected problems:

1. When you miss the private (off-chain) data for a message, you don't know which messages this blocks
- This can lead to "stop the world" scenarios, where the only safe thing to do is to stop processing anything
- Most business solutions can use a "topic" (such as a customer ID, or business transaction ID) to discriminated sequences that need to be ordered
- By specifying a `topic` in the message, an app can state which sequence it's involved in, so if you miss a message, then _only that sequence_ becomes blocked - the other sequences can continue.
2. Putting an identifier in all messages on a `topic` leaks metadata
- Information can be gleaned by seeing that X messages happened on a given topic
- Even if the topic is hashed, you can still see that the message were interconnected
- In the architecture, we mask this strongly using:
- A monotonically increasing nonce unique to each sender
- An ID for the group (calculated as a hash of the membership list and optional name)
- To allow *global* ordering without leaking the group ID to the chain, we calculate the next-hash of all members, and match new message arrivals against that

> Note this issue does not cover anonymity of the sender of the transaction. The integration of HD Wallets, ID mixers etc. is protocol specific, and handled in ethconnect and other Blockchain Interface implementations.