[meta] composer require / install module discrepancy issues

Problem/Motivation

Inspired by #3355485: Dependencies should be 'unpacked' to the root composer.json and merged/resolved but I think there might be other situations that can cause a problem.

I did not do an extensive review of the codebase, but issue queue search didn't show up anything.

Steps to reproduce

Scenario A:
Let's assume a fictional module, drupal/module_a

module_a depends on drupal/module_b

A site owner, who hasn't already installed module_b, installs module_a.
At this point, project browser/package_manager will do composer require drupal/module_a adding it to the site's composer.json. drupal/module_b will be added to composer.lock because it's an implicit dependency.

Later on, the module maintainer drops the dependency on module_b because the functionality has been moved into core, or they've made the integration optional, or whatever other reason. They can't add an update to uninstall module_b first because it can still be used in its own right.

When the site owner updates, module_b will be removed by composer, even though it's installed on the site.

Scenario B:
There is another issue, which probably would need similar underlying infrastructure but is in the opposite direction:

Let's say the owner doesn't like module_a and uninstalls it, at this point module_b will still be installed.

Then later they want to update to Drupal 12, but module_a doesn't have a 12.x compatible release.

In this situation with cli composer, I would just run composer remove drupal/module_a and be done - as long as I'd verified it was uninstalled. If you only maintain your site with project browser + automatic updates, this isn't yet an option. It suggests the need for a 'remove' page, where you can actually remove dependencies from composer, when they're not in use.

Proposed resolution

Either of the above cases would require being able to match Drupal modules to projects, which Drupal core doesn't have any support for outside of update status - possibly the update status metadata would be the way.

When a module is installed, we could check which composer project it's in, and whether that composer project is in the root composer.json, and if it's not composer require it at that point to make it an explicit dependency of the site.

Conversely, if we have that logic, we can also show which uninstalled modules are eligible for composer removal (e.g. no modules from a project are installed).