(REF) Extract TokenSmarty::render() from MessageTemplate::renderMessageTemplate()
Most Civi message-templates have been written with a hybrid notation based on
mixing tokens (eg `{contact.first_name}`) and Smarty (eg `{$foo}` or
`{if}{/if}`). The notion here is to acknowledge that Token-Smarty is a
distinct/de-facto templating language and provide the kind of `render()` API
that you would expect from any templating language (i.e. "Give me your
template, give me your data, and let me return to you a string!").
```php
$rendered = CRM_Core_TokenSmarty::render($template, $tokenData, $smartyData);
```
None of this is new functionality. It's just a refactoring which extracts
code from `renderMessageTemplate()`, hardens it a bit more, and adds some more
testing.
This is a step toward removing `renderMessageTemplate()`. The problem with
`renderMessageTemplate()` is that only handles `$contactID` -- you can't
pass-through other data to the token layer.
Before
------
* Support `CRM_Core_BAO_MessageTemplate::renderMessageTemplate()`, which accepts
`bool $disableSmarty` and `int $contactID`.
* There is no way to pass other IDs (e.g. activity and contribution IDs) to the
token-processor.
After
-----
* Support `CRM_Core_TokenSmarty::render()`. This largely the same as `renderMessageTemplate()`, except that:
* You're not specifically tied to `subject` or `text` as the template names. The list of message-templates will accept/preserve whatever keys you input (e.g. give it `html`/`text` for current compatibility; or give `msg_html`/`msg_text` to match actual DB fields)
* `bool $disableSmarty` and `int $contactID` are combined into one `array $tokenContext`, which can pass through more fields
* If there's an exception during process, `Smarty->pop()` will still do cleanup (`try/finally`).
* `Smarty->push()` and `Smarty->pop()` only run if needed
* Add test coverage from some of the peculiar ways these notations are mixed.