439 fix

This hopefully fixes #439.

All of the crashes have to deal with websockets though the crashes were triggered in different places.

*Crashing while trying to write a UIstream message to a dead client*
We were using the `send` channel instead of using the `write` method. Using the `write` method affords an error to swallow, while sending directly on a `send` channel can cause all sorts of trouble when `send` is closed. Sending on a closed `send` channel would cause a send on closed channel panic.

*Crashing while attempting to tell a deleted block to stop sending messages to a client*
This happens when the `/ws` route is being used on a block. If the block is deleted, then the block starts shutting down operations. One of these operations is to shut down out bound connections. The API is listening on these outbound connections, and as soon as the signal that the block is shut down, the deferred `DeleteSocket` function is called. This function attempts to remove the outbound connection from the already deleted block, causing a nil memory reference panic.

*Crashing in the hub in an attempt to unregister an already unregistered connection*
I wasn't able to replicate this one. The issue was that a channel was attempted to be closed twice. However, I added a check to hub.go. So now whenever a connection is unregistered/disconnects, the channel closing operation ensures that there is a connection to delete in the connection map before proceeding with delete operations. Supposedly, this should ensure that the disconnect logic happens once.