Remove PendingAnimationTracker.

Instead of starting transitions and animations as a result of a paint,
use the refresh driver tick to do this.

This sets the transition-ready time to the current time during the next
refresh driver tick that it was started on (see mSawTickWhilePending).

This is similar to what's described in the bugs comments, and seems to
work nicely in practice.

We could easily change that (current time) by a paint-based time if
needed (when available), which would be more similar to what we were
doing. But I'd rather do the simple thing for now, and land this shortly
after the soft freeze is over so that we have time to watch out for
regressions.

There's one regression on a test that birtles wrote (using an XHR doc
and switching the timeline to a rendered doc's timeline).

We use the timeline's document rather than the target document to
determine whether to trigger animations now. That's one of the cases
where we'd keep vsync perma-running without this patch, and Chrome also
fails that test. Maybe the test should be removed / the spec should be
tweaked to allow this behavior?

This causes some progression in some CSS transitions tests too, and I
added an extra test for the vsync behavior.

Over-all this is much simpler to reason about and I think we should try
to do this.

Differential Revision: https://phabricator.services.mozilla.com/D193583

bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1864425
gecko-commit: 7fd3bd56943d8ee09efb1929911f2bfa93f1ef3f
gecko-reviewers: birtles

css/css-transitions/transition-events-with-document-change.html

@@ -7,6 +7,8 @@
 <iframe src="about:blank"></iframe>
 <script>
 promise_test(async () => {
+    await new Promise(r => window.addEventListener("load", r));
+
     const target = document.getElementById("target");
     target.style.transition = "margin-left 100ms";