Cue-related events (enter, exit, cuechange) are fired up to 250ms late,
and there is a similar latency in their display which is quite
noticeable.

The underlying problem is that we only update cues alongside the
`timeupdate` event, which is fixed at 4 Hz.

My solution is to add a separate timer to CueTimeline
(`CueTimeline::cue_event_timer_`) which is given a timeout for the
next cue event based on the current playback position and rate. This
allows for significantly more precise cue timing accuracy without a
significant performance penalty.

Additionally, several web tests were written with the expectation that
the 'time marches on' algorithm is run before video playback begins
(ie, upon loading text track cues). This behavior is not in accordance
with the spec (as outlined in crbug/1050767), so this CL fixes those
expectations and adds a new test to prevent regressing.

Bug: 576310, 1050767
Change-Id: I675f5f030a68ba9cee10e12b3e79a9b174048193
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2008079
Commit-Queue: Will Cassella <[email protected]>
Reviewed-by: Fredrik Söderquist <[email protected]>
Cr-Commit-Position: refs/heads/master@{#800148}