Improvement to email creation/sending interfaces

Problem/Motivation

Create a clearer and more useable interface closer to the direction preferred in discussions in the Core issue queues.

Proposed resolution

• Remove EmailFactoryInterface and EmailBuilderInterface::createParams().
• Instead, each EmailBuilder adds a function with name and parameters appropriate to the service it provides, which is added to a new interface. For example UserEmailBuilder implements UserMailerInterface::notify(string $op, UserInterface $user). Now UserEmailBuilder has a wider scope than before and it entirely replaces _user_mail_notify() (rather than as before replacing user_mail().
• Register each XXXMailerInterface in the symfony container for auto-wiring. The code using the service now has a proper documented interface to a service which can be loaded merely by adding a constructor argument.
• Add MailerInterface::newEmail() which returns an instance of EmailInterface that is in the initialisation phase.
• Each EmailBuilder calls this function and registers itself on the new email with addProcessor() (this being handled in the base class). It then makes various calls to setParam() and perhaps setTo(), finishing with send().
• New function EmailBuilderInterface::addProcessor() which adds a processor to the next email that is sent. This allows the code using the email service to customise the emails sent, and it's also useful for tests.
• Create a new service tag symfony_mailer.add_processor. The mailer adds all services with this tag to all emails. Add the tag to EmailAdjusterManager.
• The Mailer and Email classes are now self-contained, without any reference to EmailBuilder or EmailAdjuster. They are a candidate for adding to Core.
• Commit to 2.x, and backport to v1.x except deprecating the code instead of removing it.

Remaining tasks

User interface changes

API changes

Data model changes