Add deprecation path for buildpacks using the legacy BOM format.

[natalieparellano]

When we released the new SBOM, we created the following problem:

• Old platforms (that expect to find the BOM in a label) can't upgrade their buildpacks to the 0.7 api - or if they do, the BOM will just disappear. This means that in order to use newer buildpacks, platform operators who were using the old BOM must also upgrade their platform to 0.8+. This is a more difficult migration path than we would like.

This PR proposes that buildpacks should be able to output both the old and the new BOM formats. Then older platforms will still have a BOM in the label, while newer platforms will have both.

[ekcasey]

Thanks @natalieparellano ! I think this is the right path forward.

[natalieparellano]

Assuming this change is approved, we have two paths forward for the implementation:

(1) Ship a lifecycle patch (v0.13.3), then (at some later date) ship buildpack/0.8 - this would mean that the migration path outlined here also applies to buildpack/0.7

• Reasons to do this:
  • A more sensible buildpack/0.7
  • Nothing in the buildpack spec forbids this (the spec never says what is supposed to happen if a buildpack tries to implement behavior from another api...we have been following a convention but it was never made explicit)
• Reasons not to do this:
  • The spirit of the spec is that it's supposed to be frozen in time, and we're bending the rules a little. We'd be treating the current behavior of lifecycle v0.13.2 as a bug when the fact is we didn't think of this migration path when we wrote buildpack/0.7

(2) Ship buildpack/0.8 with this change, then ship a lifecycle minor (v0.14.0) - this would mean that buildpack/0.7 only allows the new bom format, whereas buildpack/0.8 allows both old and new

• Reasons to do this:
  • A spec release is a clear signal that there is a difference in behavior
• Reasons not to do this:
  • The cadence of buildpack/0.6: old bom format, buildpack/0.7: new bom format (only), buildpack/0.8: old and new bom format is weird and could be confusing for buildpack authors
  • The lack of migration path in buildpack/0.7 would make it practically unusable for buildpack authors who care about maintaining compatibility with older platforms

Edit: you may use emojis to express preference for option 1 (🎉 ) vs option 2 (❤️ )

[hone]

Thanks for leading the charge on this! I'm glad we're adding more things into this part of the file.

I'm not going to block the path that everyone seems to want here since there's a real problem that is hurting customers. That being said, it feels like we're getting by on a technicality here. I ranted at @jromero during OH yesterday on this topic, but if we're having such a hard time working with our spec process and how it's stuck b/c it's frozen, maybe it's time to revisit that line in the sand. Just to be concrete here, we're adding a Buildpack API 0.7 deprecation in Buildpack API 0.8 release. Is it worth talking about having "patch" releases of the Buildpack API?