Web Animations: Timeline should not advance during task execution

Previously the animation clock was only frozen during animation frame
callbacks. This meant that the timeline was able to advance during other
tasks.

This patch allows the clock to advance once per task, either to the
compositor supplied frame start time or to an approximation of the next
expected frame time.

http://dev.w3.org/fxtf/web-animations/#script-execution-and-live-updates-to-the-model

This is a reland of r173583[1], the previous patch hit added assertions
due to double rounding issues, the new approach avoids these. Also ensures
that other unit tests see a non-zero currentTime (seen in some webkit_unit_test
runs on Android).

[1] https://src.chromium.org/viewvc/blink?view=rev&revision=173583
BUG=367903
TBR=abarth

Review URL: https://codereview.chromium.org/275753002

git-svn-id: svn://svn.chromium.org/blink/trunk@174346 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Don't allow script execution inside ChildNodeRemovalNotifier

Previously we would synchronously run scripts that were blocked on
stylesheets loading underneath the didLoadAllScriptBlockingResources()
call. This is dangerous since it means if you removeChild() an element
that is blocking the load it'll happen inside ::removedFrom. Similarly
it meant that the stylesheet loading code had to be very careful when
it called into this notification since script could destroy the sheets
we were in the process of loading.

Instead we use a timer to continue the script execution in the future.
This changes the execution order in some edge cases, but pages should
be resilient to this already since Firefox already behaves this way.

This also changes the order in which the load event fires on a
<link rel="import"> with respect to blocked <script>'s making the load
fire before the script. That seems sensible, though stylesheets are
the other way around. In general our system is not deterministic
with that since we use a single linkLoadEventSender() across all
documents, so there's no easy way to control when a load event really
fires as the Timer could have been scheduled at any arbitrary point.

Note that the fast/html/imports/import-dynamic.html test now fails, this
is because it depends on ordering that's not correct or spec'ed. I
rebaselined it with the FAIL lines for now. I'll fix it in a different
patch.

Review URL: https://codereview.chromium.org/296693002

git-svn-id: svn://svn.chromium.org/blink/trunk@174347 bbb929c8-8fbe-4397-9dbb-9b2b20218538