[Plan] Move more functionality into package_manager sub-module to enable project_browser use case

Problem/Motivation

Currently we have the sub-module package_manager which a thin wrapper around the composer_stager php library.
Eventually the project_browser will probably also use package_manager(when it is core directly) to install it's modules

There are several reason why instead of just wrapping composer_stager package_manager should also handle some drupal specific task

1. sites should be prevented from updating core and installing a new module at the same time
2. classes like \Drupal\automatic_updates\Validation\ValidationResult may make sense to be shared
3. firing events before different stages might be shared functionality
4. path exclusion. excluded public and private file folders and certain settings files will be the same in both cases.

Proposed resolution

Move common functionality that is not specific to updating Drupal core

For instance ComposerExecutableValidator may make sense to be in `package_manager`

\Drupal\automatic_updates\Updater make need to extend ComposerRunner in package manager.

On way we could do this is to have a test module that installs new Drupal modules so that we would have use case for both an installer and an updater. We could remove this test module when `project_browser` starts to have this functionality.

API changes

Probably a lot.