Make symfony mail delivery layer more useful to contrib

Problem/Motivation

Follow on from 📌 [PP-1] Add symfony mailer transports to DIC Postponed .

A) The legacy Drupal Core mail code by itself supports only a single mail backend PhpMail.php without a config UI. This is rather limited so 100k sites use the 8.x branch of Contrib mailsystem. However Core provides a framework to support more complex scenarios. In MailManager.php there is configuration to define many mailers, with look-up based on module and key. The mailsystem module fits perfectly on top of Core providing a GUI to set the configuration.

Another case is themes: Core supports configuration of just one main (non-admin) theme, but implements a framework that makes it easy for Contrib to vary the theme in complex ways.

B) The new symfony-based mail code by itself support only a single transport (which must be one of the 4 core ones) without a config UI. Again this is rather limited and many sites will presumably use Contrib to extend. Candidate contrib code is currently in progress here (https://git.drupalcode.org/project/symfony_mailer/-/tree/2.x/modules/mai...) but eventually here https://www.drupal.org/project/mailer_transport → . It could eventually be the replacement for mailsystem - and given the code is a natural evolution of the 1.x code already in use on 40k sites.

I see important differences in the work in this issue compared with part A. Core provides little code that is useful to Contrib, because it creates framework classes that only meets the limited needs of Core. Contrib therefore ignores them and create a new framework. Arguably it's inefficient for the community to maintain two frameworks. Especially so as the limited Core one that gets all the attention (thorough tests, detailed reviews, careful maintenance), whereas Contrib that most main sites use gets maintained by someone like me in their spare time.

Proposed resolution

We could potentially some code from Contrib into Core. The #numbers below refer to comments in the original issue.

1. A UnifiedTransportFactory service that decorates Symfony\Component\Mailer\Transport, and exposes fromDsnObject() and fromString(). This replaces TransportServiceFactoryTrait (a service is better than a trait as it allows reuse of more code including the auto-wiring constructor) . See #131.1, #141.
2. A multi-transport, very similar to Symfony\Component\Mailer\Transport\Transports, which is a very simple class and of course it works perfectly well with just one transport. See #131.2, #136, #140.
3. Support 3rd-party transports. The design for this has not yet been agreed.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet