[alerting] add doc about use of mustache double- and triple- braces in action parameters

[pmuellr]

When the actions associated alerts are run, the parameters set from the alert are interpreted as a mustache template, with a context of variables available for use in mustache directives. Typically, you'd add something like the alert name somewhere in a message body as {{alertName}}.

With mustache, there's two ways of using that directive alertName above - double or triple braces:

• {{alertName}}
• {{{alertName}}}

The difference between them, is that the double braces form will provide HTML escaping. Why, you ask? Who said anything about HTML??? Welp, that's just the way it is with mustache given it's origins. And that's why triple braces exists. No HTML escaping.

For most purposes, customers should be fine with {{}} and it will provide safety when used in any action that ends up sending HTML - today that's only the email action. Even with the email action, we generate HTML by treating the message text as markdown, run in a strict mode where it doesn't allow access to HTML. Still better safe than sorry, I think, using double- instead of triple- braces when you can.

That still leaves some cases where you might need to use triple braces - if you have a directive that has a < or & character in it, for example. You would typically see this when you run the alert, and notice your < chars have been turned into <.

Since none of this is obvious or intuitive, we need to doc it, and then we should probably provide some hints/tips about using them, maybe in the "context variable picker". That hints/tips can just be a link to the doc.

Would be a good item for a FAQ of some kind, as well.

[elasticmachine]

Pinging @elastic/kibana-alerting-services (Team:Alerting Services)

[pmuellr]

I suspect that once we get the general escaping problems fixed with the action variables, we'll no longer need to force anyone to "triple-brace" their variables, as we'll be doing appropriate escaping everywhere. We'll still "support" triple-bracing, if a customer really needs it for some reason, but by default it should never be needed.