Rework how we cache APKs

[jonjohnsonjr]

Fixes chainguard-dev/apko#772
Fixes chainguard-dev/apko#773
Fixes chainguard-dev/apko#780

Rather than caching the entire APK, we will cache the APK sections separately. It is trivial to recombine them using cat to produce the exact original APK, so we don't lose any data.

Doing this gives us two useful things:

1. The process of splitting the APK is relatively expensive, as we have to parse the targz stream to know where to split, exactly. We can amortize this across builds by doing it once per APK.
2. The individual sections have content hashes in the APK data model, so we can use those hashes as keys in the cache (filenames). When we write to the cache, we compute the hashes ourselves, so we get cache invalidation for free.

[jonjohnsonjr]

Cold before:

apko publish --keyring-append  --repository-append  --arch amd64    13.19s user 4.11s system 112% cpu 15.437 total

Cold after:

apko publish --keyring-append  --repository-append  --arch amd64    13.59s user 4.08s system 124% cpu 14.236 total

Notably, we aren't waiting for fetchPackage to finish writing the file to disk before we start running ExpandAPK, so the overall execution time drops.

Warm before:

apko publish --keyring-append  --repository-append  --arch amd64    13.12s user 4.68s system 223% cpu 7.971 total

Warm after:

apko publish --keyring-append  --repository-append  --arch amd64    10.24s user 2.61s system 187% cpu 6.851 total

Notably, we no longer pay the price of ExpandAPK on cache hits, because we do that once on cache misses and cache the results.

We shave off a second of execution time, and we also do ~20-30% less work gunzipping APKs.