Tracking issue for RFD 739 (Instance restart during live update)

This issue exists to track the work laid out in https://rfd.shared.oxide.computer/rfd/0739

• Add a new column on the vmm table to mark that we are stopping the VMM for an update. Instead of making it a boolean, we should use the update_disposition generation so that it's clear when this action was triggered. - https://github.com/oxidecomputer/omicron/pull/11127
• Background task to set the VMM as "stopped for update" when the sled's update disposition is set to Evacuating. https://github.com/oxidecomputer/omicron/pull/11170
• Background task that gathers all VMMs with that marker and asks each sled agent that owns these VMMs to stop them.
• Modify the instance update saga to account for VMMs that stopped due to an update. It should record on the instance records that it is eligible for the restart policy.
• Create a new policy for the instance reincarnation background task. It should now reincarnate instances that meet these three criteria: (1) they’re in the Stopped state, (2) the reason they are stopped is due to a system update, and (3) the intended state is not Stopped. We want to make sure they are not intended to be Stopped because that would mean a user stopped them deliberately.
• Omdb command to be able to test functionality and operational knobs.
• Have a separate "successive restarts" cooldown policy for instances that were restarted due to an update (5 mins), and the rest (1 hr)