JRFC 32 - Split TLS into two protocols

# a warning to the wise

Do not do what is described below blindly. If you ever attempt to write a secure channel protocol, you will need to pass your final design, and then your protocol implementations, through many security and cryptography experts (djb) who should tear it apart for you. Not doing so is (probabilistically) dooming yourself and your users to communicating in the clear.

---
## TLS is about two things

(this idea originates in ipfs, namely [this PR](https://github.com/jbenet/go-ipfs/pull/34) and a few conversations with various contributors)
1. distributing and authenticating keys of two parties wishing to communicate (X.509).
2. given keys, establishing a secure communication channel between the two parties.

I claim TLS should really be a layering of two protocols handling each of these concerns. I'm sure some standard exists somewhere in the literature, but I have yet to find it. For now, i'll dump ideas here regarding this effort.

---

For my purposes, I only need 2. above, the establishing of a secure channel. Thus, I propose to rip out the (thankfully simplest) part of TLS into its own protocol. A few notes:
- for compatibility, keep the same cypher suite naming (IANA TLS codes)
- keep cypher suite negotiation handshake
- handshake optional, protocol can be initialized with specific keys and cypher suite choice, making every byte encrypted (note this requires out of band session key derivation for DHE)