Worker pool should share queue instead of round-robin distribution

[kkaefer]

From #1455:

4ccf246 intensified this problem by changing our worker pool from a shared queue to an individual queue for every thread with round-robin distribution of WorkRequests. This means there can be situations where a thread's work queue gets clogged up with work items while other workers would be available to process them.

[jfirebaugh]

I am not sure we want to do this, actually. Two reasons:

• JS uses round-robin, not a shared queue. This would be different.
• I want to introduce an affinity between a map thread tile and a particular worker thread, like js has, so that there can be persistent data associated with the tile on the worker thread.

Ref #1691.

[kkaefer]

This would be different.

It may be different, but it'll improve the speed of the app quite a bit by using the cores more effectively.

I want to introduce an affinity between a map thread tile and a particular worker thread, like js has, so that there can be persistent data associated with the tile on the worker thread.

This may make sense in a JS environment where you have to copy over data to the workers, but in C++ we can move this data between threads for free, so an affinity is not required. I also think it's not desired since it may cause situations where tile distribution across threads is out of balance, requiring more work.

[jfirebaugh]

In addition to assigning work to threads more efficiently, the implementation should ensure that:

• An individual worker's work is performed in the order that it was queued
• An individual worker is not active on multiple threads simultaneously

In other words, each worker should have its own serial, FIFO execution queue, but any individual item can be processed on whatever thread in the pool is available.