CRM-19690 - crmMailing - Pick editor layout using template_type
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`).