Invasive pre-processing in 1_prune.sh can be avoided by using `ostree checkout`

I bumped in your project when I spotted the https://github.com/blue-build/cli/issues/217 issue and was surprised to see someone else had come up with the same solutions to many of the problems with custom ostree overlays (e.g. replacing kernels, SELinux labeling, improve layer reuse) independently. I've been using the same techniques since April and noticed a few differences in how we do things. The primary difference is that I use bluebuild to apply workarounds (e.g. /usr/etc merge and /etc/passwd truncation after overlay) prior to re-chunking and don't need to do any of the permissions rewrites you do due to using podman mount to access the final merged ostree image. You can see my workarounds here: https://github.com/prydom/my-ostree-build/blob/ed2b05b29bac9dc0152862f198f166b63380c044/recipes/fedora-kinoite-laptop.yml#L199-L215. I have had no booting problems. The key insight I think you're missing is that ostree-ext-rs does most of what the `1_prune.sh` script does by applying permissions captured into the ostree metadata during the initial ostree commit. By checking it out (using hardlinks mean we don't waste space) using `ostree init && ostree checkout` you avoid having to do the prune permissions steps which hardcode assumptions about how the distro applies permissions. See https://github.com/prydom/my-ostree-build/blob/ed2b05b29bac9dc0152862f198f166b63380c044/.github/workflows/build.yml#L63-L157 for my full solution.