Switch to using run-tests.sh by default

+1 For this change! It really makes a huge difference on modules with a huge set of tests. For a fact, @Berdir was the person who made me aware of the GitLab CI variable to enable concurrent test runs. Been adding that variable to quite some projects now.

Agree that it is the sensible default. The only reason why it's not is because this was added after the plain PHPUnit. For this reason, I don't think that we should just switch it, at least without a proper handling of BC.

Initial MR created. Need to work on BC now. We need to detect if _PHPUNIT_EXTRA is used and if it is, then see if the project has overwritten _PHPUNIT_CONCURRENT. If it hasn't that, means that we need to throw a warning and either fail, or set _PHPUNIT_CONCURRENT to 0 and throw a warning.

Projects using _PHPUNIT_EXTRA: https://git.drupalcode.org/search?group_id=2&repository_ref=main&scope=b...

I suggest creating a _RUN_TESTS_EXTRA variable, empty by default.
Then, I think this could be a way to go.

Almost no template will have this explicitly set, as it is the default so far.
- If _PHPUNIT_EXTRA is not empty, then we need to warn the users that they need to set _PHP_CONCURRENT: 0 if they want to continue using it. We can actually set the value in the .pre job and then display a warning.

- If _RUN_TESTS_EXTRA is empty, and there is value in _PHPUNIT_EXTRA (and _PHP_CONCURRENT is set to 1), we populate it like this: _RUN_TESTS_EXTRA: $_PHPUNIT_EXTRA and display a warning message for users to change to the new format.

This means that the templates have not overridden _PHP_CONCURRENT nor _PHPUNIT_EXTRA. These are the challenging ones, as something that was working might suddenly stop working.

I guess the only way to go about it is to show a warning message about it saying that it has changed. We could potentially run concurrent first, and if these fail, then non-concurrent, and then show the warning to users, but this would mean a double run (money++) and then maintainers might decide not to change it.

I think that the warning at the beginning of the job, right before running the tests, might be enough.

From @berdir via slack: https://drupal.slack.com/archives/CGKLP028K/p1718272288626879

@fjgarlin in case you need more reasons to push the change to using concurrency by default, https://git.drupalcode.org/project/hal/-/merge_requests/7/pipelines is a good example. test execution time goes from 30min to <3min after adding that

If we work on a 2.x effort, we should probably unify and only have one way to run the tests. I guess like core, with "run-tests.sh", but we'd need to coordinate with them to see if this is also the long term goal for running the tests.