Some systemd-boot fixes

[Johan-Liebert1]

sd-boot: Make sure timeout is written

bootctl install always writes a loader.conf file and our custom
timeout was not being written to it because we were only conditionally
writing it if loader.conf didn't exist, which was never true.

Unconditionally write it after bootctl install

Fixes: #2558

---

bootctl: Pass --variables=yes when not a generic image

If we're not installing to a generic image (eg. via loopback), we'd want
to update the EFI firmware variables similar to what we do in the
bootupd install path by passing --update-firmware

bootctl doesn't install variables if --root is given unless we also
explicitly provide --variables=yes

Fixes: #2557

[cgwalters]

I know this is just moving existing code but since we're doing that...this doesn't seem like something bootc should be hardcoding.

It should be easy and ergonomic to define the initial config file for systemd-boot as part of the container image itself.

So we should move this into e.g. fedora-bootc's base config or so. Or the package.

I really don't like having a new parser for the config file. (Which btw, could easily have unit tests)

[vonbloom]

I tested this PR (5685e48) with our installer: an Arch-based image (systemd 262, not derived from
fedora-bootc), bootc install to-filesystem --composefs-backend --bootloader systemd run through
podman run --privileged --pid=host ... from a live ISO, in an OVMF VM.

--variables=yes (#2557): the install now fails right after bootctl copies systemd-boot:

Copied "usr/lib/systemd/boot/efi/systemd-bootx64.efi" to "/tmp/.tmp9DgsgP/boot/EFI/BOOT/BOOTX64.EFI".
Failed to determine current boot order: Operation not supported

systemd treats a container as not booted with EFI: in the same container bootctl status prints
"Not booted with EFI or running in a container, skipping EFI variable modifications.", also with
efivarfs mounted. Without the flag bootctl skips the variables; with it, it fails. Since
bootc install runs in a container, I don't think bootctl can write the entry from there. The
fedora-44 systemd-boot CI failures may be the same thing (systemd >= 258 gets the flag, CentOS
10's 257 doesn't), but I can't see the logs. efibootmgr --create does work in that container
once efivarfs is mounted (bootc already mounts it), which is what our installer does after
bootc install today.

timeout (#2558): works (tested with --generic-image to get past the above): loader.conf
ends up as timeout 5 + #console-mode keep and the menu counts down from 5 s. Nit: the file
has no trailing newline.

On where the config should live: our installer writes the whole loader.conf (timeout,
console-mode, editor, auto-entries, auto-firmware), so a way to ship the initial loader.conf in
the image would help non-Fedora images more than a timeout in fedora-bootc's config. bootctl install can't take it from --root (it only writes its commented template when the file is
missing), so bootc would still have to copy it to the ESP.