…Hook::mailingTemplateTypes.

This adds two new fields to the schema.

Template types can be declared (along with preferred editor) using
hook_civicrm_mailingTemplateTypes, e.g.

```
function mymod_civicrm_mailingTemplateTypes(&$types) {
  $types[] = array(
   'name' => 'moasico',
   'editorUrl' => '~/crmMosaico/EditMailingCtrl/mosaico.html',
  );
}
```

Note: This only stores data.  Other commits will make use of that data in
more meaningful ways.

Present API consumers with a consistent, array-based interface for reading
and writing properties in a Mailing.

Suppose you're submitting a REST request to create a mailing.  The REST
request as a whole is encoded with JSON.  With the default API behavior, you
would need to double-encode the `template_options`, e.g. roughly

```
POST rest.php
  json_encode([
    entity => Mailing
    action => create
    params => [
      template_options => json_encode([...])
    ]
  ])
```

With this patch, you only need to encode the request once.

This parallels the approach used in CaseType API (for the XML `definition`
field).

General notes:

 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, check the `template_type` and load the appropriate editor.
 4. Some of the boilerplate from `2step.html`, `unified.html`, etal has been moved to `base.html`.

Note that this breaks a hidden feature -- 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';
}
  }
}
```

…nstream styling

… `static`

This function is only called once, and it previously lacked test coverage,
so the `static` warning previously snuck through. Fix it!

…public

These two functions will be useful in FlexMailer's DefaultEngine.

This is more significant with mailing tokens because some of them are fairly
sizeable/expensive.

This includes support for both `{mailing.*}` and `{action.*}` tokens used in
CiviMail.

…erage

If you install an extension under `$cmsRoot/vendor/org.example.foo`, the
resulting URL contains an extraneous `/` (eg
`http://example.org//vendor/org.example.foo`).  (In Windows, I suspect it's
even worse because it uses DIRECTORY_SEPARATOR in the URl -- eg
`http://example.org/\vendor/org.example.foo`.)

This patch checks for and removes the extraneous slash -- and always
constructs the URL with the appropriate delimiter (`/`).

Problem observed in `dmaster`.

During development of FlexMailer, I flirted with using a special token (e.g.
`{actions.trackOpen}`) but ultimately found that was positioned well in
the order of operations.