[PP-1] The install queue should be tolerant of page refreshes

Ready to go!

This probably means that the current state of the install queue needs to be sent to the page in drupalSettings

I think this means we should move the state of the installations (basically, whatever's in \Drupal\project_browser\Controller\InstallerController::setRequiringState()) into its own service, then inject that service into the ProjectBrowser element so it can add everything to the drupalSettings object.

This isn't a stable blocker for Drupal CMS. It might be a stable blocker for Project Browser, but given the way Drupal CMS intends to expose Project Browser (based on the designs I've seen most recently), it's not a blocker for us.

I'd like to advocate for not making this a beta blocker. It shouldn't change our PHP API, and the Svelte code is internal, so although this would be a UX improvement, it could surely be a post-beta feature.

Are there any rules around changing any "JavaScript APIs" for beta for Drupal? This probably got marked beta as a "boy it would be nice" so I'm ok downing it. I'm just gunshy over "API changes" - if we only care about the PHP API, then I'm comfortable because I'm sure most if not all of this solution is on the Svelte side.

The Svelte code is not an API, full stop. There is no way that I'm aware of for any external code to extend or integrate with it. All of the API exists on the PHP side.

So we can change the frontend whenever we want.

After discussing APIs with Adam on Zoom, I think this can safely move to stable blocking. I do consider it a shortcoming that we can't be tolerant, but after looking at all the APIs and where they _might_ change as a result of implementing this, we don't think there's any breakage--if anything, just possibly an addition, if at all.

So I'm re-triaging to stable blocking.