Add support for listing paid site templates in the installer

@pameeela signed off on this in a Zoom with me. She felt that the styling needs a little bit of tweaking, but that need not block the functionality. We can do that in a follow-up MR in this issue.

Merged !850 into 2.x and cherry-picked to 2.1.x. This lays some underlying foundations for implementing this, by fleshing out and encoding the information needed to display both free and paid site templates in the installer.

Merged !851 into 2.x and cherry-picked to 2.1.x. This adds more infrastructure, plus critical (but heretofore missing) test coverage:

• Added a build test, which is a full end-to-end test of installing Drupal CMS with site templates under various scenarios. I added two tests -- requiring a site template via Composer, and selecting a site template that is provided by an alternate repository.
• Added an installer extension point: the site directory may contain a site-templates.php file, which returns an array of site templates in the same format that site-templates.yml does. But this allows hosts to control the list of templates, or control it per-site, rather than always pulling a remotely curated list. If it exists, site-templates.php overrides the remote list. This is exercised by the build test.
• Added test coverage to confirm that the blank site template is always listed first, and is chosen by default.

The next step is probably setting up some kind of way to ask for, and accept, an authorization token for downloading site templates from authenticated repositories (such as Dripyard's, or the eventual marketplace).

Merged !848 into 2.x and cherry-picked to 2.1.x. This is the big one, folks: it adds support for a site template requiring a license key for installation.

This basically implements what's described in #3575464: Paid site templates in the installer: how it might work, with the glaring omission that e-commerce or payment is not handled. The idea is that you click a button to open a new tab where you buy the site template from the vendor, at which point they give you a license key (a UUID-like string). You enter the license key into a modal dialog, and the following happens:

1. Composer is informed about the repository where the package comes from, and saves the license key in the project-level auth.json as a bearer authentication token.
2. The installer confirms that the package is available to Composer. If not, it deletes the authentication token and flags an error. The idea here is that the server will not reveal the existence of any package that the license key does not grant access to. If Composer can't "see" the package, it's not installable.
3. If the package's availability is confirmed, installation proceeds as normal.

This all has end-to-end test coverage, which is why they pay me the big bucks. Writing that build test was tricky, but worth it.

@mherchel took a crack at the styling and UX for this. It surely could use some fine-tuning, but we can do that in another MR in this issue. So, the only remaining task here is for @pameeela (and ideally @ckrina) need to review this workflow and provide actionable feedback to @mherchel.

Note that, since no paid site templates are currently exposed, none of this is visible in the UI right now. You actually have to modify the site-templates.yml file to see it, much like it looked in this commit. (Upon request, Dripyard can give you a license key to test with.)

Merged !852 into 2.x and cherry-picked to 2.1.x. It extends the test coverage I added in !848 to prove that the actual downloaded ZIP file (the "dist", in Composer jargon) is also protected by the bearer access token. This means we have a full, fairly realistic, end-to-end test of installing a premium site template.

@mherchel's changes in the styling and behavior of the site template form look pretty good to me, so I merged it into 2.x and cherry-picked to 2.1.x.

One sticking point is what happens if you enter a bad license key -- the form will kick you back, but the button to edit the license key says "Already purchased? Enter license key", which is weird. It should probably be "Edit license key ❌" or something to indicate that it's a problem.

We can handle that in either a follow-up issue, or another MR in this issue. I feel fairly strongly about this because we really need the purchasing flow to be finely-tuned, since money is changing hands.

Merged !855 and !856, which broadly complete the licensing picture:

• @mherchel implemented and fixed up the UI flow for entering, validating, and saving license keys for specific site templates. There were a couple of simple backend pieces involved, but mostly this was a front-end effort. @pameeela tweaked the styling in some spots.
• @andyg5000 implemented a lightweight server-side license validation mechanism. The existing Composer-based validation continues to happen as well.

Is it perfect? No. Is it fully as squeaky-clean as it could be? No. But it is good. Drupal has never done anything like this, and we need it.

The main thing this doesn't have is any UI test coverage. This is a problem, because the UI is complicated and any tweaks run a real risk of breaking it. The problem is that it takes place in the installer, and there is no testing framework for performing functional JS tests of the installer.

Except, like, Cypress end-to-end tests. But that shit is scary and much more complex than we need. This may be a case where we have to take advantage of core's Nightwatch/Playwright infrastructure. And that, I think, can happen in a follow-up issue -- or yet another MR in this one.

Well that took a lot of work…but we’re all done here.