Reorganise initialization

### Motivation
Open Bazaar is going to become a real desktop application. However, it is currently mainly console based. All initialization is entangled and scattered around the place outputting to console whenever it likes. In a true desktop application when the application starts, the first priority would be to show something to the user in order to be obvious that the application is alive and show the initialization progress there. In my opinion this is really important to fix before we switch to nodewebkit. The usability and the friendliness to end user (especially to a not tech-savvy user) would be greatly improved.

### Solution
This Pull request moves most I/O that takes place during initialization to a dedicated thread. This thread is created when the `MarketApplication` is created and makes it possible to show the web interface as fast as possible and also let the initialization thread show progress messages to the user. In order for this to happen with minimum changes, this PR creates a dummy websocket handler that is used during the initialization. This dummy handler discards all requests that come from the web interface. When initialization is completed it is replaced by the original web socket handler to let the application work.
In order for that to work properly a fix was added in the dht to update the list of the peers in the web interface when a handshake takes place. This is needed because initialization takes place in a completely different order than before and without this, the web interface would show a small subset of the known peers.
is this `self.handler` a `ProtocolHandler`

Maybe better naming can help us avoid mistakes, given that python does not have static typing it's quite easy to put one handler on the wrong variable.

Is the `InitializationHandler` the object that runs on that dummy thread you mention while we try to get the Web Interface up as soon as possible?