Decompress function runtime tarballs once when loading

[negz]

Description of your changes

#24 added support for gzipped function runtime image tarballs by streaming each one through gzip.NewReader directly into go-containerregistry's tarball.Image.

go-containerregistry calls the tarball.Opener it's given once per layer, plus once each for the manifest and config. Because the gzip opener re-opened and re-decompressed the whole file from the start on every call, loading a single image decompressed it once per layer.

My project uses Nix's dockerTools, which emits one layer per store path, so a typical function image has ~50 layers and was fully gunzipped ~54 times. Computing the image digest then re-reads every layer again. With functions built concurrently, a project with a dozen multi-arch functions spent over ten minutes pegging every core in this loop.

This PR decompresses each gzipped tarball once into a temporary file and serves every opener call from that plain tar. The temporary files back the returned images lazily, so they must outlive Build; the builder now creates them under a per-build temporary directory and exposes a Close method that removes the directory once the caller has finished consuming the images. NewBuilder returns the concrete *realBuilder so callers can defer Close, and the build, run, and render entry points do so after they have written, sideloaded, or loaded the images.

On a project with twelve functions built for amd64 and arm64, loading all twenty-four images drops from over ten minutes to roughly eighty seconds.

This follows on from #21 and #24, which introduced pre-built and gzipped function runtime tarball support respectively.

Fixes #

I have:

• Read and followed Crossplane's contribution process.
• Run ./nix.sh flake check to ensure this PR is ready for review.
• Added or updated unit tests.
• Linked a PR or a docs tracking issue to document this change.
• Added backport release-x.y labels to auto-backport this PR.