REF Simplify tokenProcessor code

[mattwire]

Overview

This does two things:

1. Don't cast entity to an object in evaluateToken. We can just use the array directly.
2. Simplify getReturnFields() and improve performance by building arrays outside the foreach loop and clarify what variables mean. Update to reflect that fieldMapping no longer has arrays as values.

Before

More complex to understand.

After

Simpler and easier to understand. Performance of getReturnFields() improved (slightly).

Technical Details

Comments

[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).

[aydun]

@mattwire I've eventually got round to looking at this ...

1. Array instead of object - this make sense.

2. fieldMapping maps from the token name to the API fields required to construct the token. Using arrays allows more complex tokens to be handled that require more than one API field. For example, an address token might want ['street_address', 'city', 'postal_code'] Although that is not needed for the current activity tokens the extra flexibility in CRM_Core_TokenTrait may be useful for other entities so I would be in favour of keeping that.

[mattwire]

@aydun Thanks for reviewing - I hadn't considered that you might want to map a single token to multiple API fields but that does make sense. I'll back out that part of this PR and add some commenting to make that clearer.

[mattwire]

Have addressed comments from @aydun and should now be good to merge

[mattwire]

Merging based on @aydun review