use setTimeout instead of requestAnimationFrame

Since browsers expect requestAnimationFrame to be used for visual animations,
they feel free to scale down the rate at which requestAnimationFrame is invoked
when they think the user isn't looking. For example, In a background tab, Chrome
stops invoking the callback completely while Firefox throttles it to once a
second. This starves a playing video of data in a background tab. To address
that problem, this patch switches the usage of requestAnimationFrame to
setTimeout at 60 FPS.

Now, setTimeout is also throttled in a background tab (but thankfully not
completely turned off). When we're only getting one callback a second, appending
only one 1/60 of a second's data each tick quickly stalls the player. Therefore,
this patch changes the append function, so that it just appends a whole second
worth of data if it thinks its being throttled. This is admittedly a rather ugly
solution. I also tried estimating the current "FPS" of setTimeout to calculate
how much to append at each tick get to the per-second append goal. However, that
seemed to work worse than this simpler solution, partially because it caused a
feedback loop where larger appends led to longer setTimeout intervals.