Fix multiplexing between partitions and make fetch thread long-lived

There was an issue where having one partition at the end would
cause it to block, waiting for new messages, starving out the
other partitions. Instead it should move on to partitions
that have data to serve.

Simply looping over the list of partitions was incompatible with
having a timeout on the read, since that would require some sort
of time.sleep between iterations. On a system serving 10,000 messages/sec,
even a 1ms sleep is problematic.

Instead, the threading in the partition and partition registry were
re-worked so that:

1. The fetch thread is always running and keeping the internal queue full
2. A queue of partitions with available messages is kept in the registry
3. The consumer uses the queue of ready partitions to choose which to use
4. The start/stop state management of the partition fetching is now more
   explicit.