Clean up Java 27 compatibility hack

[Col-E]

Compatibility commit: 05b54eb

Compatibility logic: https://github.com/Col-E/SourceSolver/tree/master/src/main/java/software/coley/sourcesolver/util/compat

Somehow the parser factory call didn't totally break.

// Build parser for source and extract the end-pos table so that we can resolve AST ranges
JavacParser parser = factory.newParser(source,
		false /* keepJavadoc */,
		true  /* keepEndPos */,
		false /* keepLineMap */
);

The contract is different now, but doesn't immediately cause problems.

// Build parser for source and extract the end-pos table so that we can resolve AST ranges
JavacParser parser = factory.newParser(source,
		false /* keepJavadoc */,
		true  /* keepLineMap */,
		false /* parseModuleInfo */
);

We may want to also have some compat logic for building the parser instances...

---

Rant

This dogshit compatibility hack exists because we don't have maven/gradle support for Java 27 yet, but people already noticed because they try and run consuming projects on bleeding edge releases... yay.

I would have liked to use multi-release jars, but oh my god this is impossible. Because we use --add-exports we cannot use --release. And guess what mutli-release support in Maven/Gradle loves to use? Yeah.

I'm sure there's a way around it but I wasted 2.5 hours on this already...

---

Most javac internal changes can be found here:

• https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Acushon
  • 31058: Clean up calls to deprecated getStartPosition and getEndPosition methods
  • 29994: Don't require a CompilationUnit for end position APIs
  • 29463: Store end positions on more trees
  • 28610: Store end positions directly in JCTree