Refactor mail to produce an intermediate "bag of strings" object in preparation for SMS

Summary:
Depends on D19954. Ref T920. This is a step toward a world where "Mailers" are generic and may send messages over a broader array of channels (email, SMS, postal mail).

There are a few major parts here:

• Instead of calling $mailer->setSubject(), $mailer->setFrom(), etc., build in intermediate $message object first, then pass that to the mailer.
  • This breaks every mailer! This change on its own does not fix them. I plan to fix them in a series of "update mailer X", "update mailer Y" followups.
  • This generally makes the API easier to change in the far future, and in the near future supports mailers accepting different types of $message objects with the same API.
• Pull the "build an email" stuff out into a PhabricatorMailEmailEngine. MetaMTAMail is already a huge object without also doing this translation step. This is just a separation/simplification change, but also tries to fight against MetaMTAMail getting 5K lines of email/sms/whatsapp/postal-mail code.
• Try to rewrite the "build an email" stuff to be a bit more straightforward while making it generate objects. Prior to this change, it had this weird flow:

foreach ($properties as $key => $prop) {
  switch ($key) {
    case 'xyz':
      // ...
  }
}

This is just inherently somewhat hard to puzzle out, and it means that processing order depends on internal property order, which is quite surprising.

Test Plan: This breaks everything on its own; adapters must be updated to use the new API. See followups.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T920

Differential Revision: https://secure.phabricator.com/D19955