Clean up Java 27 compatibility hack

Compatibility commit: 05b54eb0fabf4b57702d875d808d9ea219c4283d

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.

```java
// 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.
```java
// 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