Persist issuable escalation statuses on issue update

What does this MR do and why?

• Related issue: Existing incidents don't have corresponding sta... (#356215 - closed)
• Related MR: Remove backfilled escalation statuses (!83159 - merged)

Together with !83159 (merged), this MR resolves a bug in the incident escalations feature, which blocks rollout of the feature flag.

Short version: There are some Issue.incident records which don't have a corresponding IncidentManagement::IssuableEscalationStatus record. Attempting to update these attributes in the UI fails without meaningful error. This MR solves that by creating IssuableEscalationStatus records on an as-needed basis.

Expected behavior:

• If a user updates the incident status or escalation policy for an incident which does not yet have an IssuableEscalationStatus record, we should create the record with the provided value.
• If issue is associated with an alert, we want to pull in the escalation policy from the alert and to update the status on both the alert and the incident with the provided value.

This is behind the :incident_escalations feature flag, so I've not included a changelog.

Screenshots or screen recordings

Setting_status

Updating_policy

Setting_status_with_alert_480

^^ This should be an unexpected use case in combination with !83159 (merged). But 🤷, it works anyways.

How to set up and validate locally

1. Create a couple incidents
   • directly by creating an issue w/ type incident
   • via a test alert
     • Also create an escalation policy for a more complete test
2. Enable feature flag

   Feature.enable(:incident_escalations)

3. View incidents & see that status & policy is listed as 'None'
   • if you created the incidents with the feature flag enabled, it also works to delete the records via rails console (Issue.incident.last.escalation_status.destroy!)
4. Edit the status from incident -> it should save without error
   • if the incident is from an alert & the project has an escalation policy, a refresh should reveal the escalation policy for the incident/alert
   • updating the status of an incident which has no status should be mirrored on the alert
   • updating the status of an alert associated with an incident which has no status will not be mirrored on the incident (this is being handled as a separate case)
5. Edit the policy from an incident (if not associated with an alert) -> should save w/o error & set the status to Triggered

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.