Run all tests on GitLab CI, replacing Drupal CI

@tedbow gave me his blessing to merge this before he went on vacation for a week.

Here's where we're at:

• RIP, Drupal CI. We knew ye well, and you were a good testbot, but time has come to lay down and cross the rainbow bridge. You can't see it, but I'm pouring a beer out for you.
• Hello, GitLab CI! All tests are passing on it, including all build tests, and we're reaping the benefits of running multiple test types in parallel. That said, CoreUpdateTest is still so very slow that our test runs take nearly as long as Drupal CI did.
• TemplateProjectTestBase needed heavy refactoring in certain spots, in order to make fewer assumptions about the layout in which it's being run. No business assertions were changed; the only stuff that's really different here is the way the test site is created.
• There are two things that the build tests really need in order to work properly. First, they need a top-level composer directory to be present in the workspace; it's the same composer directory you'd get from a core clone. The tests don't care how that directory gets there; it just needs to be there. They will fail if it isn't.
• They also need a top-level core directory in the workspace, as you'd see in a core clone. Same deal; they don't care how it got here. Just that it's there.
• All dependencies of the test site -- including third-party dependencies, and the ones provided by Drupal core -- are defined in the vendor.json file generated by createVendorRepository(). That's the only source of truth.
• GitLab CI is also running the standard contrib code quality checks. They're passing. A few changes had to be made (stuff that changed in core 10.2.x, upstream), but they're all set.
• We are not testing this module as a core module. I think a secondary/downstream pipeline should be implemented specifically for this, in another issue.

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