Try: Demonstrate cons of decentralized editor loading

[tyxla]

What?

This PR is an experiment - DO NOT MERGE.

This experiment is in the context of #35503, where we aim to refine the editor loading experience and wait for everything to load before we show the editor canvas.

Based on #42183, this experiment aims to prove that a decentralized mechanism for loading the editor will fail, because there's no way to be sure that the editor has truly finished loading. One second after we think loading has finished, a new request might (and will) get initiated, to load more of the essential data. So we can't assert that if all present data requests have been resolved, then loading has finished - new requests might be triggered afterwards. We could debounce for a second or two to ensure no requests are triggered before marking the editor as "loaded", however we have no guarantee it will be enough time, and we'll still unnecessarily add artificial delay to the editor's loading experience, which is unwanted.

Why?

The goal of this experiment is to prove that we'll need a centralized place to list all essential data dependencies of the editor, in order to properly track if they all finished loading or not.

See #35503

How?

This uses #42183 to log the resolving of all data (start and finish), and additionally logs an entry to the browser console, either when all in-progress pieces have been resolved, or when at least 1 starts resolving again. Disregard the initial state - we could as well make the selector return null or false if no requests have been started yet.

Testing Instructions

• Open the editor with your browser console open, and observe the messages.
• You'll notice that the editor "fully loads" a few times in the loading experience.

Screenshots or screencast

[tyxla]

Closing as this experiment has done its purpose and has been superseded by #42525.