Ability to specify a custom Trace Tag in a rule definition

Trace Tags allow users to easily trace whole execution flows through the system.

If trace tag is not provided by the user (e.g. via API when executing an action / when dispatching a trigger / via webhook / etc.) it's automatically generated by the system.

Right now a custom trace tag can't be set when execution is triggered by a rule. It would be handy if user could also specify a custom trace tag inside a rule definition. This trace tag would then be used for the incoming trigger and subsequent action execution.

For example, something like

---
    name: "sample_rule_with_webhook"
    pack: "examples"
    description: "Sample rule dumping webhook payload to a file."
    enabled: true

    trigger:
        type: "core.st2.webhook"
        parameters:
            url: "sample"

    criteria:
        trigger.body.name:
            pattern: "st2"
            type: "equals"

   trace_tag: "github-st2-pr-{{trigger.body.payload.pr.id}}"

    action:
        ref: "core.local"
        parameters:
            cmd: "echo \"{{trigger.body}}\" >> ~/st2.webhook_sample.out ; sync"

The idea is that there are a lot of external events (webhooks from 3rd party services) where you can't set a custom trace tag (or even if you can, via headers or similar, you can't include "dynamic" info in that trace tag).

Doing that in a rule would come handy in many scenarios, including the one above - it would allow us to easily see all the executions which belong to a specific PR number, etc.

A slightly "problematic" part is that trace tag is initially created when a trigger enters into the system. This means we would either need to update initial auto generated trace tag on the trigger which matches a rule inside a rule engine or leave that one alone and only set trace tag on subsequent executions, but not the original trigger itself (not ideal since trigger can't be traced back to the execution anymore).

Start by tracing how a rule definition, incoming trigger, and subsequent action execution are handled, then locate where the initial trace tag is generated and propagated. Define and test whether a rule's dynamic trace_tag updates the original trigger, later executions, or both, including the webhook example and the unresolved traceability tradeoff.