TokenProcessor - Allow defining Smarty variables which are opulated from tokens

TokenProcessor - Allow defining Smarty variables which are opulated from tokens

Overview
--------

This allow more interoperability between Smarty expressions and tokens.  For
example, suppose one had a contribution-related message that could use the
Smarty variable `$theInvoiceId` and/or the token `{contribution.invoice_id}`.
This revision allows the Smarty variable to function as an alias for the token.

Before
------

The caller would need to precompute Smarty values, eg

```php
$theInvoiceId = civicrm_api4('Contribution', 'get', [
  'select' => 'invoice_id',
  'where' => [['id', '=', $contributionId]]
]);
$p = new TokenProcessor($this->dispatcher, [
  'controller' => __CLASS__,
  'schema' => ['contributionId'],
  'smarty' => TRUE,
]);
$p->addMessage('example', 'Invoice #{$theInvoiceId}!', 'text/plain');
$p->addRow(['contributionId' => 123]);
```

After
-----

The caller can declare a Smarty=>Token alias and leverage token data-loader.

```php
$p = new TokenProcessor($this->dispatcher, [
  'controller' => __CLASS__,
  'schema' => ['contributionId'],
  'smarty' => TRUE,
  'smartyTokenAlias' => [
    'theInvoiceId' => 'contribution.invoice_id',
  ],
]);
$p->addMessage('example', 'Invoice #{$theInvoiceId}!', 'text/plain');
$p->addRow(['contributionId' => 123]);
```

Comments
--------

The target token must be populated via `civi.token.eval` (e.g `$e->token('foo', 'bar', 'value')`).
This would work with `CRM_*_Tokens`.  But if the token is evaluted by other means (eg
`CRM_Utils_Token::replaceGreetingTokens()`), then it won't currently be resolved.