[this is now used in https://github.com/osbuild/bootc-image-builder/pull/1157 and green there]

This PR move the bootc-image-builder code into
cmd/image-builder and changes `main()` so that image-builder
becomes a multi-call binary. When image-builder is called with
argv[0] as bootc-image-builder it will use the cobra commandline
and code from bootc-image-builder.

There is still a bit of duplication in the manifest generation
and building between bib_main.go and main.go but that is hard
to avoid if we want the "new" bib to be as close as possible
to the existing one (e.g. we do things like "canChownInPath()"
in bib which we do not need in ibcli).

One important difference between the two is how `anaconda-iso`
image types for bootc handle the repositories. The `bib` personality
stays the same as the orignal, i.e. it will use the container
repositories for depsolving. This require some complicated mTLS
handling that does not map well into ibcli. Here we do not do
that and instead use our own repos for the detected distro. I.e.
if the detected distro is fedora we build the (rpm) installer from
out fedora repos. We can strive to unify this and add (not so nice)
code into ibcli to support this or we just warn in ibcli if
bootc with anaconda-iso is used that this behaves differently
from bib and that people should use bib if they need the old
behavior (I would prefer that). I hope then we can phase out
this rpm based bootc anaconda-iso in favor of the container
based bootc-installer type.

This is https://github.com/osbuild/bootc-image-builder/pull/1131
but directly in ibcli instead of doing the bib intermediate step.
The advantage is that we can "freeze" the bib repo and if we
run into issues with the transition have the last known good
bib code. Once we are happy we just delete all go files in the
bib repo and it just becomes a repo that builds the container
for bib.

It has many commits because it imports the full history of bib/cmd/bootc-image-builder.

/jira-epic HMS-8839