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.
The check doesn't make sense in `get_pubkey`: there is always a `pubkey` around, either the provided or the derived one.

`None` is probably better. However, asking for the private key of a `Cryptor` initialized with only a public key is some kind of programming error, and I 'd like it to fail harder.