[Mailer] Add RemoteTemplateEmail to send emails rendered from provide… - #64782

Motivation

Most transactional email providers can render an email from a template hosted on their side, configured with a template reference and a set of variables. Symfony Mailer currently has no abstraction for this, which has led to inconsistent, bridge-specific hacks:

• the Brevo bridge gives a special meaning to the templateid and params headers (which, as noted in [Mailer] Clarify some tests cases for Resend transport #63196 (comment), escaped review on the initial bridge submission);
• the Mailjet bridge maps the X-MJ-TemplateID / X-MJ-TemplateLanguage headers;
• the Mailgun bridge forwards a template parameter.

Previous attempts to extend this header-based approach to other bridges (#63196, #63223) were rightfully rejected: repurposing header names inside a bridge creates hidden restrictions and breaks the transport abstraction.

However, the underlying feature is interoperable — virtually every provider with a Symfony bridge exposes the exact same pair {template reference, variables map}:

This is the same situation that led to TagHeader / MetadataHeader: one common concept, provider-specific payload mappings. This PR follows that precedent, but without headers.

Design

use Symfony\Component\Mailer\RemoteTemplateEmail;

$email = (new RemoteTemplateEmail())
    ->from('hello@example.com')
    ->to('user@example.com')
    ->template('welcome-v2', ['firstName' => 'Fabien', 'orderId' => 42]);

$mailer->send($email);

• RemoteTemplateEmail extends Email carries the template reference (a string; each bridge casts to its native type) and the variables. Since the body is rendered by the provider, ensureValidity() allows sending without a local text/HTML part — and rejects an email that defines both a local body and a template. A local subject remains allowed (providers support overriding it). Serialization is preserved so async sending via Messenger keeps the template.
• RemoteTemplateTransportInterface is a marker interface implemented by transports that support the feature. Each one maps the reference/variables to its native API payload.
• Explicit failure instead of hidden behavior: AbstractTransport::send() throws a LogicException when a RemoteTemplateEmail with a template is sent through a transport that does not implement the interface (SMTP transports, sendmail, not-yet-migrated bridges…). No header name is reserved, nothing is silently dropped. NullTransport implements the interface so null:// setups keep working.

This addresses the concerns raised on the previous attempts:

1. "Special meaning for header names" → no headers involved; the feature is part of the component's API surface.
2. "Bridges are not SDKs" → bridges only map one interoperable concept, exactly like they already do for tags and metadata.
3. "No interoperable common case" → see the table above; the abstraction is limited to the {reference, variables} pair that all providers share. Anything provider-specific beyond that stays out of scope.

What this PR does

• Add RemoteTemplateEmail and RemoteTemplateTransportInterface to symfony/mailer, with the fail-fast check in AbstractTransport;
• change Email::ensureBodyValid() from private to protected in symfony/mime (BC-safe) so the subclass can adjust body validation;
• implement the interface in three bridges with different payload styles to demonstrate the mapping: Resend (template.id / template.variables), Brevo (templateId / params), SendGrid (template_id / dynamic_template_data);
• deprecate the templateid and params magic headers of the Brevo bridge in favor of the new abstraction.

Out of scope (by design):

• per-recipient variables / batch personalizations: one message = one set of variables;
• any other provider-specific template option.

Other bridges (Mailjet, Postmark, Mailtrap, MailerSend, Mailgun, SES…) can follow in separate PRs, including SMTP transports of providers whose relay supports templates through documented headers (e.g. Mailjet's X-MJ-TemplateID).