Add a container compiler pass to add service aliases

Problem/Motivation

As of recently, core services that satisfy certain criteria (I'm not sure which!!) need to have a service alias which is their class or interface, to allow autowiring.

E.g.

  config.factory:
    class: Drupal\Core\Config\ConfigFactory
    tags:
      - { name: service_collector, tag: 'config.factory.override', call: addOverride }
    arguments: ['@config.storage', '@event_dispatcher', '@config.typed']
  Drupal\Core\Config\ConfigFactoryInterface: '@config.factory'

SNIP

  config.importer.factory:
    class: Drupal\Core\Config\ConfigImporterFactory
    arguments: ['@event_dispatcher', '@config.manager', '@lock.persistent', '@config.typed', '@module_handler', '@module_installer', '@theme_handler', '@string_translation', '@extension.list.module', '@extension.list.theme']
  Drupal\Core\Config\ConfigImporterFactory: '@config.importer.factory'

However, this is extra boilerplate. For services that don't have an interface, it's even just repeating the relationship but the other way round!

This is information that can be deduced automatically in most cases:

1. Determine whether the service should have an autowiring alias
2. How many interfaces does the service implement?
- 1: Use that as the alias
- 0: Use the class as the alias
- 2+: Is not autowired (AFAIK?)

This could be done in a new compiler pass.

It's been pointed out that this reduces discoverability, but autowiring aliases needs better documentation anyway -- https://api.drupal.org/api/drupal/core%21core.api.php/group/container/10 doesn't say which services are autowired and https://www.drupal.org/node/3323122 I *think* says the rules I've used to the algorithm above but I'm not entirely sure.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet