[ResponseOps] allow rule executors to pass an alert UUID when creating an alert

[pmuellr]

spawned from the flapping meta issue https://github.com/elastic/kibana/issues/142876

As part of https://github.com/elastic/kibana/pull/143489, we changed the alerting framework to generate unique UUIDs when new alerts are created (which had not been previously active). The lifecycle rule executor in the rule registry was changed to start using this UUID, instead of generating it's own before.

The persistance rule executor has a different issue. It creates kibana.alert.uuid fields which are actually SHA's of data specific to the alert (which makes a lot of sense for persistant alerts). And so the UUIDs generated by the alerting framework after the referenced PR is merged, won't be appropriate at all for those rule types.

Instead, we should allow the alert UUID to be passed in on the alert factory's create() call, via a new parameter. Currently the alert factory create() method has one parameter - the "instance id" of the alert. Perhaps the parameter should be an object with a uuid property, for future option "growth"). The framework would then use that value instead of generating one itself.

Until that sort of change is made, the persistent rules values of kibana.alert.uuid in the event log (only place this is currently tracked within alerting, persistently) and in the alerts-as-data indices for persistent rules, will be different. For the lifecycle rules, they will be the same.

If we don't want to make that new parameter "public", we could consider instead providing some sort of accessor function to set it, after the alert is created, exposed through the persistent rule executor framework (to limit the scope of usage).

Also note, we'll have to figure out what we want to do if we're already tracking an alert (and it's UUID) in the task state, the alert becomes active a subsequent time, but a different UUID is passed in. Error? Ignore? Use the new value? Error seems best, but I think we'll need some help from persistent rule developers to understand this better.

[elasticmachine]

Pinging @elastic/response-ops (Team:ResponseOps)

[pmuellr]

Going to leave this open, but noting that this is likely throw-away code for once we implement Framework Alerts As Data (FAAD), and could (unlikely) make finishing that effort harder.