Consider deriving from fedora-bootc

[cgwalters]

The Anaconda ISO has historically been built with lorax, and more recently osbuild.

One thing I'd love to see is support a spike on what it'd look like to build Anaconda as a bootc container image - and then the step of "create a live ISO" would be done via bootc-image-builder. I tried to create space for this in osbuild/bootc-image-builder#165

The "internal" benefit here is basically having the center of gravity shift more towards container images - the disk images are secondary. Superficially, Anaconda from a user PoV would remain the same to start.

But this technical change would start to make more obvious the road to a few valuable things:

• As a customer who wants to create a bootc image with a custom kernel (for hardware enablement etc.) today precisely because the Anaconda ISO isn't built as a container but in an "osbuild way" inside bootc-image-builder, I can't literally just do FROM <mycustom image> RUN dnf -y install anaconda or so, but I'd also need to ensure that my custom kernel is provided as an RPM input to the bootc-image-builder process. The deep division between the two build systems is obvious here.
• It'd suddenly make it more obvious that we should support podman run --privileged quay.io/fedora/anaconda ... - and especially if we made it support takeover installs it'd be a quite flexible new way to do "reimaging" of systems, using Anaconda without dropping to rebooting into an ISO, etc. (Some of this may be possible of course today by just dnf -y install anaconda, I haven't tried, but running from a container is nicer I think for this)
• It'd be a great forcing function for us to generalize the case of "build a generic Live ISO" that we definitely want for a ton of use cases (as exists today for Fedora CoreOS but also the desktop Live ISOs etc.)