Automatic Worker Fallbacks

[runspired]

This is similar to #4, but for specific cases.

On ui-threads a full app instance will be needed, along with full data-knowledge.

Ideally a ui-thread wouldn’t need to spawn it’s own worker setup.

Shared workers (#7) would solve a lot of problems, especially on mobile where you don’t want to spawn as many threads.

Data-sharing between threads is likely going to need to be done via localStorage lookups.

Since Interface is well defined and within our control (e.g. it’s not a wild west of worker interaction to account for), we could package worker.js twice, once for single-threaded use (as fallback.js) and once for within a unique worker (as <worker-name>.js

Since there's the theoretical chance the fallback would land on the main thread, we may want to add special backburner queues for scheduling and performing the operations.