Investigate updating just the kibana.* field mappings on existing alerts-as-data indices

[mikecote]

Related to: #168959

Given we update existing alerts-as-data indices to mutable fields, it would be worth investigating if we should only update the mapping of those mutable fields (mainly kibana.*) to avoid having ECS (and other) mapping conflicts down the road.

To have the latest ECS mappings for the newly written alerts, we would have to consider one of the two options (or a combination of them):

• Rollover the index after updating the mappings. This will cause a new index to be created with the latest mappings for newly written alerts. We'll need to think about scenarios where multiple Kibana instances triggering rollovers, or frequent upgrades causing rollovers.
• Update the mappings of the current write index to have the latest mappings. Some failure / fallback scenarios will need to be thought of.

Note: If ever an ongoing alert is updated by the framework in an older index, we would be relying implicitly on the ignore_malformed capability to prevent errors updating those documents. If there's a way we can make this more explicit, great!

[elasticmachine]

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