[policy, no patch] Automatic Updates & Project Browser, should NOT handle dependency management for projects not known to Composer

Problem/Motivation

Automatic Updates and Project Browser are being developed in contrib with a plan for Drupal core inclusion. They are both using package_manager an API module, currently in the Automatic Updates project, to handle Composer operations.

Unless we explicitly do not support it users may assume that Automatic Updates and Project Browser are compatible with dependencies that are declared in the projects that installed in non-Composer ways(just copied into the file system).

These projects not known to Composer:

1. Will all have info.yml files that have a core requirement in core_version_requirement
2. May have dependencies on other drupal project in their info.yml file
3. May have a composer.json with dependency on drupal/core
4. May have a composer.json with dependencies on other drupal/* projects
5. May have a composer.json with dependencies on vendor dependencies

package_manager uses the Composer Stager library to run the Composer operations in a staged version of the site

Possible problems that could happen when running Composer operations in the staged site with example project_a if it was not installed via Composer when

1. install exact same project project_a via Composer, is installed in different directory
2. install exact same project project_a via Composer, overwrites the existing project_a
3. install new project project_a, but is actually other_org/project_a, is installed in different directory
4. install new project project_a, but is actually other_org/project_a, overwrites the existing project_a
5. install new project_b that has dependency on project_a but is actually, other_org/project_a installs project_a in different directory
6. install new project_b that has dependency on project_a but is actually, other_org/project_a overwrites existing project_a
7. install new project_b that has a version specific dependency on project_a, version conflicts, installs project_a in different directory
8. install new project_b that has a version specific dependency on project_a, version conflicts, overwrites existing project_a
9. update project_b which has new dependency on project_a, installs project_a in different directory
10. update project_b which has new dependency on project_a, overwrites existing project_a
11. Update drupal core, new version conflicts with core_version_requirement in project_a
12. Update project_b, project_a has info.yml dependencies on project_b, version conflicts

Probably many more problems, these took 10 minutes to think up

Proposed resolution

1. Prevent composer operations that will result in duplicate Drupal extensions. This has been implemented now in `package_manger` in contrib #3305568: Create a validator that detects duplicate info.yml files in the stage on apply
2. Do not allow any newly installed Composer packages to overwrite existing folders, see contrib #3305564: Create a validator to stop newly installed packages from overwriting existing directories on apply

This 2 validations should stop the problem 1 to 10 described above.

Problem 11 & 12 are existing problems with using Composer and that fact that we declare dependencies in info.yml. You would run into this problem currently if you have any projects not installed via Composer

Remaining tasks

Follow up issue, see comment #18