Refactoring and unit testing of routingtable (part 1).

### Motivation
The `routingtable.py` module has fallen out of sync with the rest of the project in terms of documentation and use. It has a number of bugs and design flaws, and none of its code is tested. This PR refactors most of the minor functional units of the module, fixes a few bugs and installs unit tests for all of the new code as well as most of the existing code, too. There will be a second PR adressing the design issues and more severe bugs head-on.

### Changelog;
* Add a `hash` interface in `guid.GUIDMixin` and an `iter` interface in `kbucket.KBucket`.
* Test `KBucket.addContact` works properly with `str`, `unicode` and `guid.GUIDMixin`.
* Drop unused `TimeoutError` class.
* Bring docstrings up to scratch and use python naming conventions as much as possible.
* Refactor and test class hierarchy.
* Abstract ID space; fix bugs due to magic numbers.
* Test and refactor `getContact`, `kbucketIndex`, `removeContact`, `distance`, `touchKBucket`, `getRefreshList`. Make `distance` and `kbucketIndex` fail on bad IDs. Make `kbucketIndex` fail if overlap occurs in ID space.
* Add `numToId` method to abstract conversion of `int`s to IDs.
* Have all refactored above methods handle `guid.GUIDMixin` transparently.
* Drop `_randomIDInBucketRange` method, make `getRefreshList` deterministic.
* Drop `TreeRoutingTable.addContact` as it is broken, unused and difficult to test. As a result, `TreeRoutingTable` is an abstract class from now on.

### Roadmap:
* Make `RoutingTable` thread-safe by installing a lock on each `KBucket`.
* Move `splitBucket` method to `KBucket` class.
* Create a `SmartKBucket` that inherits `KBucket` and manages its own `replacement_cache`. Override `KBucket.splitBucket` by `SmartKBucket.splitBucket` so as to ensure the `replacement_cache` stays in sync with the `KBucket`.
* Refactor `OptimizedTreeRoutingTable` to use `SmartKBucket`s.
* Follow python naming conventions.
I disagree. These errors happen when programming errors lurk; we shouldn't protect ourselves from these otherwise we 'll never find and correct them. That's why this PR targets the `develop` branch. If there are problems to be found, or some sanitization needed, we should be reminded before the release.

One other reason I am especially against catching these two errors is that they occur when race-conditions trump the invariants of the class (i.e. that there is no overlap in the ID space). I believe there should be locks installed on each KBucket to coordinate concurrent access, and I 'd like to see if anyone's stacktrace bears that out. This testing period won't last for more than a couple of days, I have part 2 almost ready.