This is just a PoC to get the idea out. We should implement somethinglike this to warn users, if they execute PMD with incorrect javaversions. Using the wrong java version on the auxclasspath leadsto issues likepmd#4620 - the Java API changed between andtyperesolution works as designed. But with the wrong Java Runtimeon the auxclasspath, false positives are detected.You can specify the java runtime on the auxclasspath viaCLI as described onhttps://docs.pmd-code.org/latest/pmd_languages_java.html#providing-the-auxiliary-classpath .But if no java runtime is provided, we fall back to theruntime java version, which might or might not be correct.Note: For maven, there is currently no official way to configurethe java runtime onto the auxclasspath. You can workaround byadding a system scoped dependency to your project, e.g.```xml        <dependency>            <groupId>java8</groupId>            <artifactId>java8-rt</artifactId>            <version>8</version>            <scope>system</scope>            <systemPath>/path/to/jdk-8/jre/lib/rt.jar</systemPath>        </dependency>```Since maven adds all project dependencies to the auxclasspath whenexecuting PMD, this adds the java 8 runtime and false positivessuch aspmd#4620 disappear.In theory, you could also use maven toolchains to execute PMDwith the correct java version.At the beginning I think, we should issue a warning, if wedetect a mismatch between the java language version and the javaversion, that we resolve from the auxclasspath. Note - thewarning I added in this PR only appears in DEBUG mode.And I assume (needs to be verified) that we could do this checkonce at the beginning and don't need to issue a warning forevery file...Once the warning is out there and we provided enough documentationaround how to resolve this warning, we could make this into afatal error, aborting the PMD analysis. We might even thinkabout not falling back to the runtime classpath for type resolution,forcing users to always configure the intended java versionexplicitly.