Our current implementation of the HTML event-loop is in need of fixing. For this issue I am referring only to the window event-loop, which requires interacting with the rendering. Worker loops seem ok for now(we're not delivering rafs to workers yet).

Quick recap on how it is specified:

1. The event-loop picks a runnable task, and runs it.
2. It runs a micro-task checkpoint(so one after each task is run)
3. It reports long tasks.
4. It runs the idle callback logic.

In parallel(which means anywhere else in Servo, like the compositor), we must wait for for a rendering opportunity for that event-loop, and then queue a task that runs the update the rendering steps.

The task queued is then appended to a task queue, and eventually handled at 1 above. Note that this tasks runs a lot of steps, but atomically within the same task, and in a specific order.

For example, step 11 is update animations and send events, step 14 is update animations and send events, and step 15 runs the resize observer logic.

Running these "update the rendering" steps in that way allows for a certain level of determinism. For example, if one requests an animation frame callback from within the last notification callback of a resize observer, one can be certain that by the time the next resize notification is invoked, the animation frame callback will have been invoked first. This resize observer test is an example of relying on that ordering.

Quick recap on how the current implementation:

1. We select on various channels, including one representing the various task queues, but also other channels representing messages from the constellation/compositor, the image cache, webgpu, and others.
2. We handle certain type of messages first.
3. We then check for additional messages
4. We then update_animations_and_send_events
5. We then process events collected at 1 and 3 above sequentially
6. We then perform a micro task checkpoint
7. We then maybe_queue_document_completion
8. Finally, we issue any batched reflows

The ResizeObserver PR adds a step before the reflows, that runs the resize observer notification steps.

The problem: our current implementation does not follow the ordering of the spec, hence it is a source of timing issues.

Solution: restructure the event-loop to only run the 4 steps it is supposed to run, and restructure the handling of all other messages as happening via a task running the "update the rendering" steps.