Give PollingProducers their own thread.

This furthers the pattern discussed here 
http://threebean.org/blog/threading-moksha/

In the initial revision, only consumers were each given their own thread(s). 
Here, pollingproducers also get one.

This fixes a bug we're seeing where our nagios checks periodically report
UNKNOWN status.  My theory is that this is due to a storm of thousands of
messages from the secondary arch koji instances.  Since the MonitoringProducer
which produces the stats and the ZMQ machinery live on the same thread, the
MonitoringProducer gets locked out while all those messages are unloaded onto
the Consumer queues.  By separating those pieces, the MonitoringProducer
should be able to continue its lightweight work unimpeded.