Make update and switch operations idempotent

[Johan-Liebert1]

Pulls in #1783

Handle the following cases we can encounter on bootc udpate and bootc switch

1. The verity is the same as that of the currently booted deployment
   - Nothing to do here in case of update as we're currently booted. But if we're switching
     then we update the target imageref in the .origin file for the deployment

2. The verity is the same as that of the staged deployment
   - Nothing to do, as we only get a "staged" deployment if we have
   /run/composefs/staged-deployment which is the last thing we create
   while upgrading

3. The verity is the same as that of the rollback deployment or any
   other deployment we have already deployed
   - Nothing to do since this is a rollback deployment which means
   this was unstaged at some point

4. The verity is not found
   - The update/switch might've been canceled before
   /run/composefs/staged-deployment was created, or at any other point
   in time, or it's a new one.

   Any which way, we can overwrite everything. In this case we remove
   all the staged bootloader entries, if any, and remove the entire
   state directory, as it would most probably be in an inconsistent
   state.

There is a lot here, and I managed to test the main code paths and the above four cases

Related: #1735

[gemini-code-assist]

Code Review

This pull request introduces idempotency for update and switch operations by checking if the target image is already present in some form. The logic is well-encapsulated in update.rs and shared between both commands. A significant and welcome part of this change is the refactoring of the Storage struct to manage the boot directory and ESP mount, which greatly cleans up the code and removes duplication across several files. Additionally, kernel argument handling is improved to preserve user changes during updates. The changes are well-structured and effectively achieve the PR's goal. I have left a couple of minor suggestions for improvement.

[gemini-code-assist]

The error message here is confusing. It says "Found NonEFI config", but it's in the _ arm of a match where the only other arm is BLSConfigType::NonEFI. This means it triggers for anything that is not NonEFI. A better error message would clarify that a NonEFI config was expected.

Suggested change

	_ => anyhow::bail!("Found NonEFI config"),
	_ => anyhow::bail!("Unsupported BLS config type: expected a NonEFI config"),