Feat/multiple platform cpes

[willmurphyscode]

PR with the goal of representing NVD CVEs that affect multiple specific platforms in grypeDB schema v5, which only supports one platform CPE constraint per row.

The transform to be accomplished is explained at anchore/grype#1042 (comment) in detail, but basically, emit a row for each affected platform, rather than emitting a single row with no platform constraint.

One thing we need to discover is whether there are lots of NVD issues that have multiple application nodes ORed with multiple platform nodes. If so, this needs to be expanded to be a cross join. - DONE, this does a cross join now.

TODO

• refactor significantly, clean up implementation
• handle nodes being in other order
• investigate whether this should be expanded to a more general configuration shape
• Consider whether this is going to work with https://github.com/anchore/grype/blob/2e9eff8f740d15ba8bc4af3e172f48e97bd8f5f3/grype/pkg/qualifier/platformcpe/qualifier.go#L20-L80 (get the unique platform CPEs that are included in the DB after this change and not included in the DB before this change, and see what the linked code would do with them.)

[willmurphyscode]

This change will roughly triple the number of unique platform CPEs present in Grype DB:

❯ sqlite3 willtmp/newdb/5/vulnerability.db \
'select distinct package_qualifiers from vulnerability where namespace like "nvd:cpe" order by id limit 10000000000;' |\
 rg platform-cpe | jq -r '.[0].cpe' | sort | uniq | wc -l
    2380

❯ sqlite3 ~/Library/Caches/grype/db/5/vulnerability.db \
'select distinct package_qualifiers from vulnerability where namespace like "nvd:cpe" order by id limit 10000000000;' |\
 rg platform-cpe | jq -r '.[0].cpe' | sort | uniq | wc -l
     819

Before merging, I'd like to take a look through the new platform CPEs and see what grype will do with them.

Edit: I think this discrepancy is because of things that shouldn't be ending up as platform CPEs. Converting back to draft PR while I investigate.

Edit on the edit:

It turns out that we use vulnerable == false to determine whether a CPE Match is a "running on/with" config, not the type o.

[willmurphyscode]

This struct is used as a map key in uniquePkgTracker. Have a pointer in a struct that's used as a hash key results in key collision being assessed based on pointer equality, not string equality. I think string equality is the right semantics. (Put another way: we wouldn't say one pkg candidate was different from another if the only difference was the memory location where the platform CPE was stored.)

I could be talked into pulling this out into its own PR.