Enable service autoconfiguration for core event subscribers

Problem/Motivation

Symfony allows autoconfiguration - automatic tagging of services that implement a particular interface.

Drupal has lots of event subscribers, and they need to both implement EventSubscriberInterface and be tagged with event_subscriber.

Steps to reproduce

Proposed resolution

Implement autoconfiguration so services that implement EventSubscriberInterface are automatically tagged with event_subscriber.

Enable autoconfiguration in core.services.yml.

Remaining tasks

Open a followup to autoconfigure core modules.
Open followups to add more tags/interfaces that can be autoconfigured.

User interface changes

API changes

Services can now specify autoconfigure: true instead of manually tagging individual services with event_subscriber.

Data model changes

Release notes snippet

Original issue summary

For a variety of reasons, Drupal's implementation of the Symfony dependency injection container does not include features from upstream, either because Drupal 8's implementation lifecycle predated certain features being included in Symfony (D8 started requiring Symfony 3 and the upstream project is now on v5) or because certain Drupalisms prevent a Symfony-like implementation (e.g., our requirement the DI container be serialized/cached into the database and not onto disk, to enable runtime module enable/disable actions.)

The Symfony DI component allows service autowiring (always possible but not really utilized; core is likely to autowire, soon) and autoconfiguration (never implemented in Drupal.) Autoconfiguration means services may be auto-registered as event subscribers, controllers, and the like, based on the service's implementation of an interface.

Changes such as #3021898: Support _defaults key in service.yml files for public, tags and autowire settings get us closer to supporting autoconfiguration. Due to Drupal's model of services.yml files per module, and the Drupal-specific way in which module services are enabled in the container, this will require some domain-specific implementation. That said, with Drupal implementing more of the native Symfony pattern for services.yml _defaults syntax, many modules could combine autowiring and autoconfiguration to remove almost all the boilerplate now common in [module].services.yml.

Autoconfiguration is a bit of a special case as that option needs to be parsed in the Yaml services definition and added to the service definition...but the actual autoconfiguration occurs in ContainerBuilder::registerForAutoconfiguration() and ContainerBuilder::merge(). The former method we do not override and as such registration could happen rather easily; the latter method is not invoked by Drupal's implementation of the kernel. I think this could actually be implemented without a significant lift, if we stay true to the upstream container builder's architecture.

I would also add here that adding support for the Yaml parser's PHP constant interpolation (see https://symfony.com/blog/new-in-symfony-3-2-php-constants-in-yaml-files) would be nice/get us more inline with upstream, but I'd have to do some issue archaeology to determine if this feature flag is omitted purposefully.