Correctly match JVM version ranges

[wagoodman]

This builds on anchore/syft#3217 being able to correctly reason about pre and post JEP 223 versions (1.8.0 = 8.0.0). Specifically, when a package is detected to be a JVM package, and the vuln data indicates it's for a JVM package, then we'll correctly reason about JVM versions when making the comparison. For instance 1.8.0_372 == 8.0.372 based on the JEP223 spec and convention of the patch version in popular jdk releases. Today this nuance is not taken into consideration.

Additionally, this PR uses the CPE update field, which is commonly used in the vulnerability field for <= v1.8 JVMs -- without using this field we could never make the correct comparison.

Closes #1718

[westonsteimel]

Hmm, something here appears to cause matches for python and go binaries to get dropped. Any ideas why that may be? It may actually be the syft changes which are causing it

[westonsteimel]

Hmm, something here appears to cause matches for python and go binaries to get dropped. Any ideas why that may be? It may actually be the syft changes which are causing it

It's something on the grype matcher side. I tried with an old syft sbom and it still drops the python binary vuln matches

[wagoodman]

Yeah, I was trying to figure out last night why this was happening -- I figured it out this morning: we stop at the first matcher that claims it can find a match for a package. The JVM matcher was making this claim for all binary type packages, which means it would stop the correct (stock) matcher from being used in other cases (like golang and python).

I added the JVM matcher to make certain we're always searching by CPE, however, in this case it's only a version comparison change and the stock matcher already searches by CPE by default. I'll remove the JVM matcher for now and let the stock matcher to continue to raise these matches up.