xdebug being enabled causes tests to fail without clear indication that it is the problem

Problem/Motivation

Steps to reproduce

Working with @travis.carden to get his tests running locally we figure the problem was that \Drupal\package_manager\Validator\XdebugValidator was failing because he had xdebug on

In Build tests this caused a failure at \Drupal\Tests\automatic_updates\Build\CoreUpdateTest::testCron because $assert_session->pageTextContains('Your site is ready for automatic updates.'); because there was message about xdebug error on the status report

for build tests 📌 Make build tests fail 1) more explicitly, 2) earlier when possible (failing StatusCheckEvent subscribers) Fixed will display the reasons "Your site is ready for automatic updates" is not displayed

failed at $this->assertCount(count($expected_results), $actual_results); where we expected only 1 result but we got 2. We still got the expect result but got an additional result for xdebug.
This is not true any more since #3320815: Make validation result comparison test messages more helpful → you would get a clear indication in the error that extra error message is dealing with xdebug. See the summary of that issue for an example

Originally Neither 1 of these gave you any indication what the error was really. Now #3320815 gives a clear indication for kernel tests and #3320792 will give a clear indication for build tests.

Proposed resolution

If xdebug is on automatically fail the test early. This can be done by calling new method in \Drupal\Tests\package_manager\Traits\AssertPreconditionsTrait::setUpBeforeClass() this will then apply to all our tests.

Add an environmental var PACKAGE_MANAGER_ALLOW_XDEBUG_TESTING to turn to not do this. In our message to the user we would mention setting PACKAGE_MANAGER_ALLOW_XDEBUG_TESTING

we will update XdebugValidator to return early if PACKAGE_MANAGER_ALLOW_XDEBUG_TESTING was set to true.

We deciding against having a setting in settings.php like PACKAGE_MANAGER_ALLOW_XDEBUG_TESTING because this could accidently be pushed to production and in the worst case scenario people might try to apply a critical security release when they did not know xdebug was enabled and it would timeout in the apply stage leaving them half updated.

Remaining tasks