Add a flag to set up test environment only once per test class; introduce setUpBeforeClass() and tearDownAfterClass() [PHPUnit]

This should be resurrected - but should be split into separate issues for Kernel / Browser / JS tests.

It feels if we had fixed this issue in 2012 the Drupal Association could save tens of thousands of dollars on CI environments.

I discussed this with @Alex Pott at DrupalCon Lille a few months ago.

His comment IIRC was along the lines of 'you can usually just comment parts out of the code'.

Here's an example where AFAICT, you can't. I want to test all the possible combinations of 4 factors. So I'm using a cross product setup. To do so with a @dataProvider would mean a kernel test setup for each combination, which is needlessly expensive.

So I'm doing the cross product manually in the test method like this:

    foreach ([FALSE, TRUE] as $permission_access) {
      foreach ([FALSE, TRUE] as $operand_access) {
        foreach ([FALSE, TRUE] as $operability) {
          foreach ([FALSE, TRUE] as $reachable) {
            $this->state->set('test_mocked_control:permission_access', $permission_access ? AccessResult::allowed() : AccessResult::forbidden());
            $this->state->set('test_mocked_control:operand_access', $operand_access ? AccessResult::allowed() : AccessResult::forbidden());
            $this->state->set('test_mocked_control:operability', $operability);
            $this->state->set('test_mocked_control:next_state', $reachable ? 'cake' : NULL);

            // Generate the links.
            $links = $action_link->getStateActionPlugin()->buildLinkArray($action_link, $user_no_access);

            // No access always means no links.
            if (!$permission_access || !$operand_access()) {
              $this->assertEmpty($links, implode(':', [$permission_access, $operand_access, $operability, $reachable]));
            }

But this has a number of drawbacks:

- I have to ensure each assertion has a custom message otherwise I will have no idea which set of values caused a failure
- furthermore, I have to use cross product values which are easily stringable, so the message can be easily made without complex code. This harms DX, as it would have been easier to read if the values for the access factors were AccessResult objects -- the checks further down would be easier to read than the boolean check for instance
- I can't run just a single combination for debugging. Or well, I can if I rewrite the cross product code like this so that values can be commented out, but it still requires a lot of faffing about to isolate a single case:

    $permission_access_values = [
      FALSE,
      TRUE,
    ];
    $operand_access_values = [
      FALSE,
      TRUE,
    ];
    $operability_values = [
      FALSE,
      TRUE,
    ];
    $reachable_values = [
      FALSE,
      TRUE,
    ];

    foreach ($permission_access_values as $permission_access) {
      foreach ($operand_access_values as $operand_access) {
        foreach ($operability_values as $operability) {
          foreach ($reachable_values as $reachable) {

All of this is reinventing the wheel which PHPUnit provides with the data provider system.

How often are we running these tests? Seems like a good investment of time to cut the execution time in half, even if it's a matter of allowing us to know earlier that the patch works.