Fix CPE target software filtering + improve logging

[wagoodman]

This changes the target software processing for CPEs such that, when we don't have a known package type (or is a binary type) we use the original CPEs on the package and vulnerability to understand if there is an overlap or not of target softwares -- this enables us to allow broad CPE matching (when a TWS of python should match with a TWS of *). Additionally for packages with known types we also do the same intersection but instead of checking for broad CPE matching we fallback to the existing logic that is there today (looking at package attributes).

In terms of the logging improvements, now refuted entries always come with a reason. The old logs look like so:

[0000] TRACE fetched affected CPE record cpe=cpe:2.3:a:snowflake:snowflake_connector:2.0.0:*:*:*:*:*:*:* duration=387.166µs records=10
[0000] TRACE dropped vulnerability affectedCPE=affectedCPE(cves=CVE-2023-34232, cpe=57950, vuln=226776) cpe=cpe:2.3:a:snowflake:snowflake_connector:2.0.0:*:*:*:*:*:*:* reason=package version not within vulnerability version constraints vulnerability=CVE-2023-34232
[0000] TRACE dropped vulnerability affectedCPE=affectedCPE(cves=CVE-2023-51662, cpe=57948, vuln=239682) cpe=cpe:2.3:a:snowflake:snowflake_connector:2.0.0:*:*:*:*:*:*:* reason=package version not within vulnerability version constraints vulnerability=CVE-2023-51662
[0000] TRACE dropped vulnerability affectedCPE=affectedCPE(cves=CVE-2025-24788, cpe=57948, vuln=281759) cpe=cpe:2.3:a:snowflake:snowflake_connector:2.0.0:*:*:*:*:*:*:* reason=package version not within vulnerability version constraints vulnerability=CVE-2025-24788
[0000] TRACE dropped vulnerability affectedCPE=affectedCPE(cves=CVE-2025-24793, cpe=57951, vuln=281764) cpe=cpe:2.3:a:snowflake:snowflake_connector:2.0.0:*:*:*:*:*:*:* reason=package version not within vulnerability version constraints vulnerability=CVE-2025-24793
[0000] TRACE dropped vulnerability affectedCPE=affectedCPE(cves=CVE-2025-24794, cpe=57951, vuln=281765) cpe=cpe:2.3:a:snowflake:snowflake_connector:2.0.0:*:*:*:*:*:*:* reason=package version not within vulnerability version constraints vulnerability=CVE-2025-24794
[0000] TRACE dropped vulnerability affectedCPE=affectedCPE(cves=CVE-2025-24795, cpe=57951, vuln=281766) cpe=cpe:2.3:a:snowflake:snowflake_connector:2.0.0:*:*:*:*:*:*:* reason=package version not within vulnerability version constraints vulnerability=CVE-2025-24795
[0000] TRACE dropped vulnerability criteria={fn:0x10193a7b0} reason=<nil> vulnerability=CVE-2023-34230
[0000] TRACE dropped vulnerability criteria={fn:0x10193a7b0} reason=<nil> vulnerability=CVE-2023-34233
[0000] TRACE dropped vulnerability criteria={fn:0x10193a7b0} reason=<nil> vulnerability=CVE-2024-49750
[0000] TRACE dropped vulnerability criteria={fn:0x10193a7b0} reason=<nil> vulnerability=CVE-2025-24791

The new logs have less addresses and more info:

[0000] TRACE fetched affected CPE record cpe=cpe:2.3:a:snowflake:snowflake_connector:2.0.0:*:*:*:*:*:*:* duration=387.166µs records=10
[0000] TRACE dropped vulnerability cpe=cpe:2.3:a:snowflake:snowflake_connector:2.0.0:*:*:*:*:*:*:* reason=not within vulnerability version constraints: "< 1.6.21" vulnerability=CVE-2023-34232
[0000] TRACE dropped vulnerability cpe=cpe:2.3:a:snowflake:snowflake_connector:2.0.0:*:*:*:*:*:*:* reason=not within vulnerability version constraints: ">= 2.0.25, < 2.1.5" vulnerability=CVE-2023-51662
[0000] TRACE dropped vulnerability cpe=cpe:2.3:a:snowflake:snowflake_connector:2.0.0:*:*:*:*:*:*:* reason=not within vulnerability version constraints: ">= 2.0.12, < 4.3.0" vulnerability=CVE-2025-24788
[0000] TRACE dropped vulnerability cpe=cpe:2.3:a:snowflake:snowflake_connector:2.0.0:*:*:*:*:*:*:* reason=not within vulnerability version constraints: ">= 2.2.5, < 3.13.1" vulnerability=CVE-2025-24793
[0000] TRACE dropped vulnerability cpe=cpe:2.3:a:snowflake:snowflake_connector:2.0.0:*:*:*:*:*:*:* reason=not within vulnerability version constraints: ">= 2.7.12, < 3.13.1" vulnerability=CVE-2025-24794
[0000] TRACE dropped vulnerability cpe=cpe:2.3:a:snowflake:snowflake_connector:2.0.0:*:*:*:*:*:*:* reason=not within vulnerability version constraints: ">= 2.3.7, < 3.13.1" vulnerability=CVE-2025-24795
[0000] TRACE dropped vulnerability reason=vulnerability target software(s) (".net") do not align with pkg(snowflake_connector@2.0.0 type="?" language="?" targets="python") vulnerability=CVE-2023-34230
[0000] TRACE dropped vulnerability reason=vulnerability target software(s) ("node.js") do not align with pkg(snowflake_connector@2.0.0 type="?" language="?" targets="python") vulnerability=CVE-2025-24791```

[kzantow]

We discussed the reason for returning, well, a "reason" from the criteria. Something about it doesn't sit well for me, though I can't really put my finger on exactly why. I understand there are some strings formatted with some appropriate context this way, but I wonder if the Criteria interface required fmt.Stringer to provide "enough" information for logs, or there's a different thing that would sit better. Regardless, this isn't something I want to hold up this PR for. I'll add a 1.0 issue to revisit this.

[wagoodman]

but I wonder if the Criteria interface required fmt.Stringer to provide "enough" information for logs

I tried that initially but wasn't able to cover all cases. Always up for reevaluating that approach for grype 1.0

[wagoodman]

Added label updates to support this PR: anchore/vulnerability-match-labels#141

[wagoodman]

I've verified that the QG matching is doing the right thing even though in some cases this is performing a little worse in the examples we have. I'll adad ignore rules for the QG for these exceptions such that we can safely merge this PR.