Add CycloneDX 1.6 Support about syft

[ragaskar]

This is related to anchore/grype#1951, as grype appears to be using the syft internal cyclonedxutil decoder for decoding. ... I may take a shot at PR-ing a fix this evening, let me see if I have enough time.

[ragaskar]

Just a quick note after digging into syft. I now believe I'm incorrect about this being the root issue behind my particular problem. It's very related in the sense that if someone updated the list of supported cyclonedx versions to include 1.6 in syft my problem would go away -- for now ... but the core problem seems to be that grype, when it emits an SBOM is simply calling cyclonedx.NewBOM, which uses the latest available cyclonedx SpecVersion by default, whereas syft (very reasonably, imo!) has their own internal list of default + supported versions.

I'd like to fix both problems and not run into the grype problem again when cyclonedx spec 1.7 comes out, so I think I might start over there.

[ragaskar]

OK, that one looks ready for review.

An update on my goal of avoiding sbom generator surprises around cdx spec versions:

1. I was incorrect about how the DefaultVersion constant I saw worked. It looks like syft is configured to pick the latest available spec version (for formats for which syft supports "all versions").
2. I think grype just unintentionally uses latest (via calling cyclonedx.NewBOM() and not using the EncodeVersion to select a specific output version) to emit. That said, after beginning to get my head around how syft encoding/decoding works, I'd suspect I should take another look at grype to see if I correctly understood the flow -- perhaps grype accepts similar configuration and there is a near-term workaround if you don't want 1.6 (beyond just pinning back).
3. For those of us concerned with surprises with backwards incompatible spec versions, syft supports configuring a cyclonedx spec either in a syft config file or by passing a "format@specVersion" pair to the output flag (e.g., -o [email protected]=some-json-1.5.cdx.json). In some ways this is the best of both worlds, the defaults encourage lib owners to quickly support newer specVersions, but as a user you can protect yourself by locking down to a version (above issue with grype aside).