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.
Merge pull request #15 from mokshaproject/feature/producers-too

Give PollingProducers their own thread.