RFE: skip updates if booted container is a superset

In CoreOS we are considering creating different boot media (i.e. bootable disk images) than upgrade media (i.e. the OCI container image in a registry that `bootc` uses to upgrade the system). The idea here is that we can include some things in the boot media that are only used on first boot that can then be dropped out of the system on upgrade. A good example of this is Ignition, where currently we ship Ignition updates to all upgrading nodes that exist, which is a waste of bandwidth during the transfer and disk space on the upgraded system.

In this scenario we can first create a "core" bootable container build (i.e. the update payload) and then create a "firstboot" bootable container build that is used to generate our boot media. @travier touches on this a bit [here](https://github.com/coreos/fedora-coreos-tracker/issues/1726#issuecomment-2145224229).

```
-> core bootable container (update payload)
|
-----> firstboot bootable container (derives from core, adds firstboot bits)
|
----> bootable disk images are created from the "firstboot" bootable
container but configured to point at the "core" bootable container
registry pullspec for updates
```

However, we don't want people who grab an image (or AMI, etc) and start up CoreOS (or any Image Mode variant that wants to use a model like this) to immediately have the update mechanism:

1. look at the registry and see the booted container image is different than the target container image in the registry
2. update the system to it

In order to support something like this we'd need to be a little smarter. An idea here would be supporting a way to mark derived containers as "containing" another image OR as a "superset" of another image.

In this case the update mechanism would look at the container in the registry (the update target) and get the hash (`aabbccdd`) and then compare that with booted hash (`wwxxyyzz`), but also the booted "contains" entry (`aabbccdd`).

If the update target hash is in either the booted hash or "contained" within the booted container the updater will no-op until that is no longer true. Once the update target hash is different the system will update and the firstboot specific bits will no longer be present on the system.