Make build tests fail 1) more explicitly, 2) earlier when possible (failing StatusCheckEvent subscribers)

re #14 I don't think belongs in \Drupal\Tests\package_manager\Traits\AssertPreconditionsTrait because

1. Status check on the status report page only applies to Automatic Updates not package manager
2. it doesn't apply to kernel or build unit tests
3. that trait uses setUpBeforeClass so it can assert conditions at the earliest possible point, hence preconditions. You can't run the status checks or that status report page at this point. Other times we don't sign with just minimal permissions necessary to do the test task which does not including assessing the status report page.
4. many test we set up the tests to have problems with particular status checks. Often there will be errors in status checks before the call to \Drupal\Tests\automatic_updates\Functional\AutomaticUpdatesFunctionalTestBase::mockActiveCoreVersion and we don't call this in setup because different test methods need to mock different versions

I think we should look at the suggestion in #17 but I think we should do the original intent of this was just provide this check for build tests. Because the build test has to rely on the UI unless we build more test infrastructure like `\Drupal\package_manager_test_event_logger\EventSubscriber\EventLogSubscriber::logEventInfo` but for running the status checks, otherwise a build test doesn't have another way to know if the status checks pass.

So I would suggest

1. revert back to https://git.drupalcode.org/project/automatic_updates/-/merge_requests/58... the last commit that I pushed that was still only for build tests. I had tried to address @Wim Leers feedback on that approach. Review and commit that approach
2. Open another issue to add an assertStatusCheckSuccessful() that would used in kernel and functional test. On that issue if we decide if that is something we can run for all these tests or if it would only make sense to call sometimes(most of the and classes have to opt out?) because certain test methods are setup specifically to fail these checks
3. in 2) decide if it makes sense to remove the UI approach in build tests in favor of calling our assert in a test module in build tests.

I think we should do 1) now because build tests are the hardest to debug and this would help a lot, even it is the final way we handle this

Ok brought in my changes into 3320792-explicit-early .

1 test failed but I pushed up a fix for it

Created #3337049: Assert no errors after creating the test project in ModuleUpdateTest as a follow up but that issue is tagged contrib-only so I am not adding the sprint tag since we don't need to do it now.

I would really like to get this in and I don't think the functional test are going to share that much code so I rescoping this the orignal

We could use the same code in functional test like I did in the original MR https://git.drupalcode.org/issue/automatic_updates-3320792/-/blob/332079...

but I think that is overkill for the functional tests to rely on the UI when I think all we have to do in functional test is to use our existing function like
$this->assertStatusCheckResults([]);

We just have to figure where to call because some functional test are step up to specifically fail status checks and other don't enable automatic_updates until later so calling
$this->assertStatusCheckResults([]); would only assert package_manager validators

and we can't simply enable automatic updates , $this->assertStatusCheckResults([]); and then disable it because some test what happens when we enable automatic_updates so doing this would change test coverage.

TLDR I don't want to figure all that out right now and put off the fix for build tests.

Created follow-up #3337054: Assert status checks pass as early as possible in kernel and functional tests

`composer phpcs` ran locally

merged 8.x-2.x , will commit when green

🎉