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.
Binary search won't help me with overlapping buckets, and this is why I will introduce it only after I 've assured myself the code is free of race conditions. Thanks for the code suggestion. I 'll see if I can use it in the next PR.