Split the sbom.Format interface by encode and decode use cases

[wagoodman]

Today there is a single unified sbom.Format interface allowing for identification, encoding, and decoding use cases. This PR splits this interface down the middle into two use cases: encoding and decoding (where encoding would subsume the identification use case).

type FormatEncoder interface {
	ID() FormatID
	Aliases() []string
	Version() string
	Encode(io.Writer, SBOM) error
}

type FormatDecoder interface {
	Decode(by []byte) (*SBOM, FormatID, string, error)
	Identify(by []byte) (FormatID, string)
}

Why do this?

Primarily, there is one core problem with how formats are constructed today: they do not allow for injection of configuration. This means that if there are any specific behavioral differences that are desired for how an SBOM is presented then the abstraction must be broken to allow for injecting that information (this is done today for templating).

Secondarily, the abstraction can lead to bad assumptions for the decoding use case. The encoding use case requires a format ID and specific version, however, when decoding neither is really needed. That is, given a pile of bytes an object should be able to produce and SBOM or not. Having a single object where you have a strong ID and version coupled with the decoder makes it seem like you need a format object per-version-per-format-id in order to work, but this is not the case.

Changes made in this PR:

• Split the sbom.Format interface into sbom.FormatEncoder and sbom.FormatDecoder interfaces.
• Replaces the Validate format functions with Identify, which more closely tracks the reason for this functions existence.
• Removes the existing sbom.Decoder and sbom.Encoder definitions. The names are not reused to prevent consumer confusion on this breaking change.
• Remove the top-level format objects (Closes Remove deprecated syft.Format functions #1344). Otherwise these functions (which are about to be imminently removed anyway) would need to be refactored to continue to function.
• Add sbom.FormatEncoder construction in the option.Output object, allowing for application configuration to be injected into the objects that are used to encode SBOMs (the main driver behind this change).
• Combines option.MultiOutput and option.SingleOutput into a single option.Output object. Both original objects have a need to craft encoders when making sbom.Writer objects. This refactor was done to make this addition simpler.
• Rename the formats package to format to be consistent with other lib packages.
• While adding a test case it became necessary to add an additional golden image fixture. Instead of adding an additional fixture golden file, I refactored testutil to be able to reuse the same fixture file for all format tests.
• Keeps the logic for cyclonedx and spdx more centralized so encoders for the same SBOM format (cyclone vs spdx) but different on-disk formats (xml vs tag value vs json) still have the same basic functionalities (such as supporting the same spec versions). This has lead to the additional versions support for cyclonedx-json (v1.5) thus the schema was updated.

Note for reviewers

the bump to the cyclonedx schemas make the PR diff look much worse than it is:

 schema/cyclonedx/cyclonedx.json                                                         | 2352 ++++++++++++++++++++++--
 schema/cyclonedx/cyclonedx.xsd                                                          | 4021 ++++++++++++++++++++++++++++++++++++-----

Fixes #2112

[kzantow]

Overall, I think this looks good. 🎉

The one general comment I had is that I don't think we should have nearly as many Default functions for this stuff. I think it should be either: a) a New constructor, or b) another constructor function that takes a configuration. Providing multiple ways to get default config AND default format encoders confuses library consumers, when they should be using the configs and constructors, not any of the default functions (aside from getting syft lib config defaults).

Lastly, I would avoid the static defaults on the decoders, too, so this doesn't have to also later get refactored to get configuration passed in.

agreed to sync later next week about more changes

[kzantow]

👍 🎉