TokenProcessor - Allow basic filter/modifier expressions

[totten]

Overview

This demonstrates how to extend TokenProcessor to support rendering token-expressions with filters/modifiers.

ping @eileenmcnaughton @mattwire

Before

Hello {foo.bar}

After

Hello {foo.bar|upper} and Hello {foo.bar|lower}

Technical Details

This only supports tokens that supply values through civi.token.eval (ie $row->token(...key-value...)). At the time of this commit, most {contact.*} tokens still use TokenCompatSubscriber::onRender() to hack-in their values and won't work until they switch over.

The regex which recognizes the filter is pretty tight (eg accepting |upper or |lower but not |myfunc:"yadda yadda"). This can be relaxed somewhat by a subsequent change, but I'd say such a change has a burden to demonstrate safety/interoparbility when running in Token-Smarty format. (e.g. demonstrate that matching of open/close symbols works correctly).

[civibot]

(Standard links)

• If this is your first pull-request for CiviCRM, please browse CONTRIBUTING.md for information about the development and testing processes.
• If you are reviewing this pull-request, you may wish to consult the test sites and the Review Standards (long template, short template).

[eileenmcnaughton]

Cool - I have a feeling that |upper would already be pretty useful (I'm sure I've written tokens in the past to do just that....)

[eileenmcnaughton]

test fails relate

[totten]

test fails relate

Ah, it wasn't working on pseudo-tokens with a : in the name. Updated the regex. ByTypeTest is now passing locally... We'll see what Jenkins has to say...

[eileenmcnaughton]

@totten I'm gonna give this merge-ready. It seems useful in itself & it works but obviously the real value is when we extend for dates. I've put a note in the dev-digest

[colemanw]

Looks good to me too.