This PR allows one to display a different CiviMail composition UI depending on the `template_type`. Key details:

 1. When creating a mailing, use the path `civicrm/a/#/mailing/new` to create a mailing with the default `template_type` (aka first-preferred, by weight).
 2. When creating a mailing, use the path `civicrm/a/#/mailing/new/{template_type}` to create a mailing with a specific `template_type`.
 3. When editing a mailing, it checks the `template_type` and loads the appropriate editor.
 4. Some of the boilerplate from `2step.html`, `unified.html`, etal has been moved to `base.html`.

Note that this breaks some hidden functionality -- before, you could switch
among a few different layouts (`2step`, `unified`, `unified2`, `wizard`) by
manually editing the URL (e.g.  `civicrm/a/#/mailing/2/unified`).  Now, to
change the layout of the traditional-style mailings, you can implement a
hook, e.g.

```
function mymod_civicrm_mailingTemplateTypes(&$types) {
  foreach ($types as &$typeDef) {
    if ($typeDef['name'] === 'traditional') {
      $typeDef['editorUrl'] = '~/crmMailing/EditMailingCtrl/unified.html';
    }
  }
}
```

Relatedly, if a downstream system has found some other way to patch/hack a
replacement for the CiviMail layout, then they'll need to update it.
(Specifically, port the changes on display in `2step.html` or any of the
other layouts.).  However, this has always been a hidden trick with
unrealistic UX -- and we've refrained from documenting/institutionalizing
it...  until now.  With this PR, overloading CiviMail UI becomes a supported
feature (by way of the public-facing `hook_civicrm_mailingTypes`).