decouple SBOM generation from image build process

[tianon]

Currently, we generate SBOMs as part of the image build process, but the only benefit we gain from doing so is marginal (rabbitmq uses ARG BUILDKIT_SBOM_SCAN_STAGE=true to scan non-final stages of the image, but the benefits gained from doing so are very unclear if existent at all).

If we decouple that and treat SBOMs as another separate "build" artifact that we can only generate once we have a build, and generate an sbomId from something like buildId + built image digest + SBOM scanning image digest, then we'd get some interesting benefits; notably:

• SBOM scanner would no longer need to run on every architecture we want SBOMs for (they'd all run on a linux/amd64 instance regardless of image architecture)
• SBOMs could be regenerated when the SBOM scanner image is updated (no longer requiring a rebuild of the image we're scanning to fix SBOM-specific issues)

Prior related art:

• Add sbom scanning command #87
• Generate SBOM for the oci-builder #51
• Move oci-import (and SBOM) shell code out of meta.jq into an explicit shell script #124

One way we could embed this is by adding an "sbom" key in builds.json next to "build" and "source" (whose order in that file I've been considering swapping, which would make it natural to have "source", "build", and then "sbom", listed in the order they have to be processed/exist).

[tianon]

The alternative thought is that we stop generating SBOMs entirely, but maybe that's too to post publicly
^{send tweet}

(The serious version of this that I saw posted elsewhere recently boils down to "SBOMs are primarily a compliance problem and it's a little bit disingenuous to shovel that compliance labor onto a free and open source project")