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 am in favour of *exactly* the opposite. Let me state my case briefly:

Python is built around the "consenting adults" philosophy; if you do not want unpredictable results, do not mess with private variables. The "underscore" system is much more friendly that getters and setters and in most cases it can be syntactically checked (see `pylint` warning [W0212](http://docs.pylint.org/features.html)). In any case, there is no failproof way to prevent access to the attributes of an object; installing getters and setters will give a *false* sense of security. If we want strict encapsulation or strict static types, we should go the Haskell way.

In any case, please consider the fact that up to this point much of the code has been developed as Proof-of-Concept by non-experts; enforcing any kind of standards compliance on any sufficiently complicated codebase is a feat unto its own. This is true for Python as well as for C and Java. Even the Haskell guys indulge in some [unsafePerformIO](http://www.haskell.org/ghc/docs/latest/html/libraries/base/System-IO-Unsafe.html) once in a blue moon.

TL, DR; When in Rome, do as Romans do; get rid of all getters/setters and use underscores and decorators. It is an error to use a language counter to its design.