I was trying to implement `testRunner.renderingUpdate()` so you could write a test like:

        window.addEventListener('load', async () => {
            await testRunner.renderingUpdate();
            debug('rendering update complete');
            // do stuff
        }, false);


However, that turned out have flakey behavior with respect to the ordering of rAF callbacks:

        window.addEventListener('load', async () => {
            requestAnimationFrame(() => {
                debug('requestAnimationFrame callback');

                requestAnimationFrame(() => {
                    debug('second requestAnimationFrame callback, which should always come after the "rendering update complete"');
                });
            });

            await testRunner.renderingUpdate();
            debug('rendering update complete');
        }, false);

Sometimes the second rAF callback happened before "rendering update complete" and sometimes after. This depended on the timing of the microtask callbacks fired from WindowEventLoop, which I believe handles the resume of the load function when the `renderingUpdate` Promise is resolved.

The source of unpredictability which I identified was the timing of the zero-delay timer in WindowEventLoop. The incorrect behavior happened when the WindowEventLoop timer fired between `TiledCoreAnimationDrawingArea::scheduleRenderingUpdateRunLoopObserver()` and `TiledCoreAnimationDrawingArea::updateRenderingRunLoopCallback()`. There's already code that tries to avoid timing firing delaying the runloop observer for long periods of time (`breakToAllowRenderingUpdate()`), so we can piggyback off that to avoid this timer firing between the scheduling and the fire of the CFRunLoopObserver that controls the rendering update.