streamer: Pass streamer events through the queue

This commit makes it possible for multiple worker processes to receive
the streamer events by passing them through an external queue.

As before, an `h.events.AnnotationEvent` subscriber is responsible for
serializing events. It now publishes them to an external NSQ topic. The
details of connection to NSQ are managed by the `h.queue` module.

When the streamer module is included by pyramid, it will start up a pair
of greenlets which are responsible for deserializing and handling the
events pulled from the NSQ topic. One of these opens a persistent TCP
connection to NSQ and receives messages, pushing them onto an internal
queue structure. The second reads from the internal queue structure, and
broadcasts the events to active websocket sessions as appropriate.

A final point of explanation: NSQ sorts messages into "topics", which
serve as a named queue, and "channels", which are associated with a
specific topic. Topics and channels differ thus:

- each message sent to a topic is copied to every channel (i.e. fanout)
- if multiple clients connect to the same channel, incoming messages
  will be shared between those clients in a round-robin (i.e. they are
  worker queues)

As a result, each web worker connects to NSQ using a unique channel
name, ensuring that each queue reader gets copies of every message
published to the topic.

At the moment, we use ephemeral channels in order to avoid messages
backing up in NSQ for web workers that have long since ceased to exist.
This does mean that in the event of a network partition between web
worker and NSQ, some messages may be lost and not relayed to websocket
clients connected to that worker.