[Meta] Create validation listeners

Problem/Motivation

We should do as much as we can from detecting errors that will not allow a update to succeed and stopping the update cleanly.

Some of the checks we can run before an update starts and others we can only check after an update has been staged.

Proposed resolution

Create a list and child issues for validation checkers we will need. Some these checkers will prevent and update and others will prevent/abort
an update.

1. #3241105: Ensure core package is validated in readiness check and pre-start
2. Done: \Drupal\automatic_updates\Validation\StagedProjectsValidation validates only expect project updated
3. #3228955: [PP-1] Handle new or deleted files in `sites/default`
4. #3231996: Ensure file system is writeable
5. #3231997: Ensure there is enough disk space to do the update
6. file ownership
7. #3232000: Ensure the composer.lock file matches existing Drupal projects
8. #3231999: Ensure Composer is version 2.x
9. #3230235: Validate that an update is supported before it begins

For each issue

1. Create a service tagged with event_subscriber that will listen to 1 or more of the update events in `\Drupal\automatic_updates\AutomaticUpdatesEvents`

   There are few validation services that be used as an example such as ComposerExecutableValidator, StagedProjectsValidation, and UpdateVersionSubscriber.

   for a general intro to event subscribers see https://www.drupal.org/docs/creating-custom-modules/subscribe-to-and-dis...

2. Each service should add validation error if they found a validation problem. An example of this can be found in UpdateVersionSubscriber:
   

   $error = ValidationResult::createError([
      $this->t('Updating from one major version to another is not supported.'),
   ]);
   $event->addValidationResult($error);
   

3. Create a test for the new service. A kernel or unit test should be sufficient. We already have general test that validation subscribers can stop an update with an error so we don't need a test for each new service.

   Example tests are ComposerExecutableValidatorTest, StagedProjectsValidationTest

4. If the validation is similar to validation that was used as ReadinesChecker in the 8.x-1.x version of this module you may consult the existing checkers in the 8.x-1.x branch for internal logic to be adapted

   Some validation will be new to the 8.x-2.x version so there will always be an existing ReadinessChecker.

5. Depending on the new service it may break other existing tests because it may stop an update unless the test site is prepared to pass the new validation. That is expected and is not a problem. If you don't know how to fix the test just mention that in a comment on the issue and someone else can help.

Remaining tasks

make the child issues