Skip unparseable Java versions in FindJavaVersion instead of reporting -1

[timtebeek]

What's changed

FindJavaVersion reads the JavaVersion marker on each source file and records its major source/target version in the JavaVersionTable. When a marker's compatibility string is empty or otherwise unparseable, JavaVersion.getMajorVersion() returns the sentinel -1. The recipe stringified that value directly into the table, so affected repositories surfaced a bogus -1 row.

Worse, the lower() reduction keeps the lowest version per repository as the migration floor, and -1 sorts below every real version — so a single module with an undetermined version dragged the whole repository's reported version down to -1, masking the real versions of every other module.

This skips markers whose source or target major version is negative. Such markers carry no usable version, so they neither emit a -1 row nor participate in the reduction. When no module in a repository has a parseable version, the repository simply contributes no row (rather than a misleading -1).

Why

Customers running FindJavaVersion reported -1 values in the results. The unparseable-compatibility case originates upstream (a toolchain-only build, an unresolved ${...} property, etc.); companion fixes harden the Maven/Gradle plugins and the core marker, but the recipe should never present -1 as if it were a real Java version regardless of how the marker was produced.

Testing

Added FindJavaVersionTest cases: an unknown-version module is skipped while its sibling is still reported, and an all-unknown repository emits no rows.