Don't consider the video paused until 100ms have passed since its currentTime hasn't changed.

requestAnimationFrame callbacks can happen more frequently than the video's currentTime property updates, leading to the pause detector incorrectly thinking the video has been paused and unpaused in the next iteration. On some browsers like Nightly, this happens very frequently because the currentTime is sometimes updated as infrequently as every 60ms. Every time this happens, the clock (and the overlying renderer) switch between paused and playing states, causing errors to gradually accumulate in the times of any animations.

This change adds a timestamp to VideoClock to record when a pause is first suspected. The clock doesn't actually enter the paused state unless the video's currentTime doesn't update for 100ms since this timestamp.

The reason for the large value of 100ms is empirically based on Firefox's above-mentioned behavior. Chrome seems to update it every 30-40ms which is probably once every video frame (23.976fps). IE seems to update it on every iteration of requestAnimationFrame (15-20ms) which suggests it's generating the currentTime independent of actual frames.
Switched to in-development TypeScript compiler.

- Union types.
- Switched default lib to lib.es6.d.ts
Implemented @implements annotations in JSDoc and documentation generator.
Use quasis for building strings.
Use destructuring assignment and shorthand property names.