Refactor and test crypto_util. Wrap pyelliptic.

### Motivation
There should be one (and preferably only one) place where `pyelliptic` and `OpenSSL` touch the codebase. The key processing should be as transparent and documented as possible, without any magic strings. All requests for cryptographic operations must pass through a strict API, which shall be tested extensively.

### Changelog
* Define a `Cryptor` class with strict API to wrap `pyelliptic`.
* Replace `makePubCryptor`, `makePrivCryptor` and `ec.ECC` by `Cryptor` class.
* Abstract and document key processing. Explicitly name all constants involved. 
* Test the entire `crypto_util` module.

### Roadmap:
Create a `Peer` (or `Identity`) class, which *is-a* `guid.GUIDMixin` and *is-a* `crypto_util.Cryptor` and *has-a* `CryptoConnection`. This means thinning the `connection.py` and `transport.py` module down to bare minimum. In order to have a semantically sound encapsulation, perhaps the `guid.GUIDMixin` should be subclassed and embelished with more attributes.

@yagoulas will work on the above, with me helping.
Well, this is a troubling point, actually, since the private key is always encoded when initializing a `Cryptor`. Looking at the [ECC.__init__](https://github.com/yann2192/pyelliptic/blob/master/pyelliptic/ecc.py#L68) makes it seem that there's no trouble if both keys are encoded on the same curve.