Listener refactor

### Motivation:
It turns out everyone uses `TransportLayer` as a dump for every method or attribute whose proper place is undetermined. As a result, this class is bloated with all sorts of code: managing sockets, listening for requests and handling various pieces of crypto code.

This is the first of a series of attempts to reduce the bloat of `TransportLayer` and factor the code into several smaller and simpler classes, more amenable to testing and maintenance.

The new `Listener` classes mirror the pattern of `PeerSender` and `CryptoPeerSender` but are designed cleanly and follow good practices such as defining all members in constructors. They are also completely independent from `dht.py` and `transport.py`, whereas `Sender` classes still have this problem and should be refactored in the future.

### Changelog:
* Factor classes `PeerListener` and `CryptoPeerListener` out of `TransportLayer` and `CryptoTransportLayer`, respectively.
* As the `Sender` classes get a `dict` that is then encrypted, compressed and sent, the listener classes do the inverse actions and receive, decompress and decrypt the messages, relaying the sent `dict`s to the receiver.
I recently saw a refactor in which @hoffmabc wanted to use a single Context.
I'm still a noob when it comes to ZMQ, I don't know if you want to keep a single Context per PeerListener.

Are we using a single TransportLayer object?

What is the proper way to work with ZMQ, can you do all your networking with a single zmq Context?
Is this ZMQ Context necessary anywhere else in the code?
If so, we should probably instantiate it outside Transport and PeerListener and pass the reference down to these guys. If not, then let's make sure we don't create more zmq contexts than necessary and that they're properly shutdown when OpenBazaar is shutting down.