Higher precision timers using WebWorkers

[3rd-Eden]

As explained in the primus/primus#350 issue it's possible that Chrome on Android is actually suspending timers when you background your application. This can have unwanted side affects. So the idea is to add WebWorker support in to tick-tock which allows you configure if you want to use a background mode when available.

Now, we probably want to use a WebWorker and a blob + the URL instance so we can create workers without the requirement of downloading additional files. In addition to that, the worker should only be started once for the lifetime of the module so all ticktock instances use the same worker instance.

[3rd-Eden]

The delay is now also measurable with the new remaining and taken methods on the timer instance. So you can get an understanding on how much your timer was delayed.

[STRML]

:+1: This appears to be biting some of our Safari clients who are being disconnected on the regular because of these inconsistent timers. I may start working on a webworker option very soon so this can get into Primus.

[STRML]

I know it could bloat the library, but how do you feel about reusing a Worker abstraction library like https://github.com/padolsey/operative? That way we get the proper blob, datauri and eval fallbacks for older browsers.

Looks like the prod minified build is about 9k. But it could be a bit heavyweight if we're really just optimizing for Chrome Mobile / Safari. But we can't guarantee that other browsers won't start doing this kind of timer deferral in the future to save power, nor that webworkers won't eventually also have their timers deferred.

[petkaantonov]

Another way is to create a audiobuffer with some inaudible samples. Then use audioBufferSource nodes of your desired duration and listen for the "ended" event. It might even work on iOS Safari but I cannot test that. A gotcha is that if you don't use an audiocontext at all for a while or play silence (e.g. 20 seconds) then you need to create a new audiocontext.