install: Add dynamic config

[cgwalters]

Things like console= kernel arguments are both platform (aws, gcp, etc.) and architecture specific.

Right now the install-time kargs are static. But, we could add something like:

/usr/lib/bootc/install-generators.d

That would just be executed in order to generate bootc install fragments in e.g. /run/bootc/install.d that would be merged in.

This way a base container image could ship arbitrary logic to e.g. inspect the target platform (whether via inspecting dmi, systemd-detect-virt, etc.) as well as architecture and compute things like the console= kargs to inject.

In the fully general case actually...it'd be nice to make it ergonomic to include active logic in a base container image that does things like inspecting the MAC address (possibly even querying a remote server) and also computing kargs at a minimum - say for e.g. static IP addresses. Take the user story here of:

• User builds container image with shell script in /usr/lib/bootc/install-generators.d that has a static table for network configuration that is per-machine and keyed off MAC addresses (or other hardware identifiers)
• User attaches a minimal installer ISO via IMPI that when launched is configured to fetch generic container image from registry
• Container executes at install time, bootc install runs the script runs and generates an install config fragment with kargs = ip="10.x.y.z" etc.

That way the admin didn't have to get into building machine specific images. (Of course, another approach is to just match by MAC address in NM keyfiles etc., but that can get unwieldy IMO, plus there are some use cases that need networking in the initramfs, which I think is usually better done via simple kargs where possible, only falling back to injecting into the initramfs if needed)

Perhaps some of this should really be a higher level wrapper for bootc install; and so that's an argument to add /run/bootc/install.d that a higher level tool could generate and then invoke bootc install, and we'd automatically pick up the pre-generated fragments.

Anyways though, short term this would simplify e.g. cloud image definitions to make it easier to support multi-arch.

OTOH, we could just add a declarative matching in install configs; trivial for architecture, less trivial for platforms.