worker usage should be customizable

[jfirebaugh]

For node, we don't want to spawn four threads for each Map instance. Instead, the node thread pool should be used.

Worker needs to be more like FileSource -- an abstract interface that can be replaced with different implementations depending on the platform.

[tmpsantos]

Wouldn't make mbgl::Worker thread-safe (it is almost already) and share it across all the map objects a more maintainable option?

[jfirebaugh]

It wouldn't be ideal for node. Node already has a built-in concept of a thread worker pool, which native extensions are expected to use for CPU-intensive tasks. The right thing for an extension to do is use that pool, not launch its own threads.

[jfirebaugh]

We now have an abstract interface that can facilitate this: Scheduler. We could, for example, write a subclass that implements Scheduler::schedule via Nan::AsyncQueueWorker. The worker Execute implementation would do:

if (auto locked = mailbox.lock()) {
    locked->receive();
}

(Actually this logic is already repeated here and here and we should extract it as static void Mailbox::maybeReceive(std::weak_ptr<Mailbox>).)

The other thing we need to do is externalize the dependency, passing a Scheduler& into the Map constructor as we do View& and FileSource&, rather than creating it internally. This will need to be a coordinated change across all SDKs.