Allow activators to generically decorate Project objects

This really turned out to be dragon-shaped but, along with 📌 Cleanup of Project object contract/constructor Active , represents a major, and critically important, clean-up of the backend code; a final twitch of the toxic myriad-tentacled monster that was the internally-tabbed Svelte data model. I was NOT kidding when I said that most of the complexity in Project Browser could be traced back to that design decision.

The overall purpose of this MR is to sort out the boundaries between EnabledSourceHandler, the activators, and the endpoint controller. And setting the proper boundaries between local project IDs (not prefixed with the source plugin ID), and fully qualified project IDs (prefixed).

Some of the salient points:

• Project objects need not know which source exposed them. This is good, because any number of sources could, in theory, expose the same project in different ways. They can have a local ID, which should be immutable. So that's why Project::$source is gone.
• The Svelte app, however, should only deal with fully qualified project IDs. That is generated at one point: in ProjectsResultsPage, which does have enough contextual information to ensure the fully qualified IDs are sent to the frontend.
• On the backend, there is only one way to load a cached Project object from storage: with its fully qualified ID. InstallState's design was getting in the way of this, and for no real point anyway -- the progress-checking route is dead code and no longer in use. So I axed it.
• A project's activation status and commands are not EnabledSourceHandler's business. It is only concerned with querying source plugins and caching the results; activation info has never been cached (and rightfully so), therefore EnabledSourceHandler should have nothing to do with activation. That moves to the one place that actually has reason to care about it, which is the ProjectBrowserEndpointController. It is the final word on what projects get delivered to the frontend, and is responsible for the final assembly of the frontend's data payload. That makes it the most natural place to attach activation data.

yeah boi

Automatically closed - issue fixed for 2 weeks with no activity.