feat: Sys extension management

[mudler]

Is your feature request related to a problem? Please describe.
currently it's hard to determine in a running system the installed system extension that are enabled for the current boot entry (active or passive), similarly, for upgrading the systextensions it is adviced to do that manually by entering the efi partition and replacing files accordingly.

Describe the solution you'd like
A way to list and manage sysextensions in the system from both the CLI and from the cloud config before installation, for example, during runtime we might want to call something similar to manage the extensions:

# shows sysexts in the active boot
kairos sysext list --active


# shows sysext available when booting in passive
kairos sysext list --passive

# Install/upgrade/removal of sysext
kairos sysext install --active <sysext path>
kairos sysext upgrade --active <sysext path>
kairos sysext remove --all <sysext> 

# disable/enable extensions
kairos sysext disable --active <extension>
kairos sysext enable --active <extension>

Additionally the sysext path could be a reference to an oci image rather to a local path.

From the installation we could have something similar to the following in the cloud config:

#cloud-config 

install:
  extensions:
  - oci://foo-bar
  - livecd://bar-baz
  - /local/path
  - https://awesome-url/image.tar

Acceptance criteria

As part of this card we should create the appropriate documentation end to end:

• how to build an extension
• how to use it (trusted boot, and non-trusted boot)
• how to manage it with the CLI ( upgrades, enabling, removing it)

From an implementation perspective:

• The commands of the CLI should be seamelessly usable from the system-upgrade-controller mechanism we already user to dispatch upgrades
• We have commands as part of the kairos-agent CLI to manage extensions (install, update, remove, enable, disable) For the various boot modes (active/passive, etc)
• Extensions can be installed during the installation by specifying the path of these in the cloud config file
• When specifying the paths from the cloud config file, we could supply local files, OCI images, remote files (tar images) or live cd paths
• Mechanism should work for both TB and non-TB scenarios. The users shouldn't care about if running in trusted boot mode or not

Describe alternatives you've considered
Keep things manual

Additional context
https://kairos.io/docs/advanced/sys-extensions/#building-system-extensions-from-a-docker-image-with-auroraboot

[Itxaka]

Some more context

• sysext extensions can be seen with the systemd-sysext status command. Show only working ones, so it ignores broken or unsigned ones
• currently no difference between active/passive extensions if they are bundled with the install media, they are applied to both
• kairos sysext upgrade --active <sysext path> should be kairos sysext upgrade --active <sysext path> <source for upgrade> as you need to know both the one that has to be upgraded and where the upgrade comes from.
• we may be able to infer the name and version from the filename, but otherwise no idea how we can get some info like systemd-dissect does (which shows a lot of info!) Would be nice to know how to

[mudler]

updated the card to include enable/disable and documentation steps for e2e usage, updated ACs