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've heard the "language for adults" bs too, one thing is the philosophy, another thing is the reality of how things are developed when you have a dynamic language that allows you to define fields during runtime.

When you have a mess with member variables named ._something, .something_similar (like before we had transport.py and connection.py), and you have to send that stuff through the wire, it is very easy to make the mistake of misnaming the values you are sending, wether you're an adult or not, after long hours of coding _ is an invitation to make mistakes and I've fixed plenty in OpenBazaar due to that particular cause, my logic is keeping things simple and as error proof as possible.

If you have all variables named without the _ notation, then there's 0 chance of screwing up messaging.
It's a dynamic language and I think it's more responsible adhering to simple consistent naming.

I'll read about the decorators, I hadn't picked up on python in years before OpenBazaar came along, and I'll still vouche for no ._members. I don't think keeping things simple goes against the design of the language.