Abstract GUIDs. Properly support unicode GUIDs.

### Motivation:
PR #686 implements `__eq__` for `node/connection.py::CryptoPeerConnection`. The implementation was borrowed from that of `node/contact.py::Contact`, which was deleted in the said PR. However, the implementation was not correct: it mishandled the case where `unicode` GUIDs are used. This PR fixes that. It also abstracts the GUID out of `CryptoPeerConnection` into a separate file.
  
### Changelog:
* Factor `AbstractGUID` out of `node/connection.py::CryptoPeerConnection` and `test/test_kbucket::AbstractGUID`.
* Add `unicode` support. 
* Supply a complete testsuite for the new class.
* Fix relevant documentation
Ok so here's the deal. The GUID is an integral part of the DHT. I don't know why we're isolating the identity from the DHT. A DHT contact is purely a GUID. The URI is really what should be abstracted out because that's just how to physically get your communication from point A to point B. The GUID however is how we determine routing in the DHT. A Contact == GUID. We are simply attaching some context to that GUID in the DHT whether it be a key-value or an actual store. 

I don't know if I'm being very clear, but I just don't understand what's the difference between a "contact" and an "abstractGUID" object?