Fix build-time Refaster template loading

[Stephan202]

Suggested commit message:

Fix build-time Refaster template loading (#121)

When using the system classloader, `RefasterCheckTest` is able to
successfully load the Refaster templates from the classpath, causing the
tests to pass. However, when during a build the Java compiler loads
`RefasterCheck`, the templates on the annotation processor classpath are
_not_ exposed through the system classloader.

To see the issue for yourself, apply the following patch and observe how before this change the redundant negations aren't flagged:

diff --git a/refaster-compiler/src/main/java/tech/picnic/errorprone/refaster/plugin/RefasterRuleCompilerTaskListener.java b/refaster-compiler/src/main/java/tech/picnic/errorprone/refaster/plugin/RefasterRuleCompilerTaskListener.java
index 7bc2d3ef..0947a468 100644
--- a/refaster-compiler/src/main/java/tech/picnic/errorprone/refaster/plugin/RefasterRuleCompilerTaskListener.java
+++ b/refaster-compiler/src/main/java/tech/picnic/errorprone/refaster/plugin/RefasterRuleCompilerTaskListener.java
@@ -54,7 +54,7 @@ final class RefasterRuleCompilerTaskListener implements TaskListener {
     }
 
     ClassTree tree = JavacTrees.instance(context).getTree(taskEvent.getTypeElement());
-    if (tree == null || !containsRefasterTemplates(tree)) {
+    if (tree == null || !!!containsRefasterTemplates(tree)) {
       return;
     }
 

[Stephan202]

This also impacts #43, and that PR doesn't actually apply the templates at build time for a second reason; will also push a commit to that branch.

[rickie]

Code changes LGTM.

I have one question as I fail to understand why. Why does this (not) happen?

However, when during a build the Java compiler loads
RefasterCheck, the templates on the annotation processor classpath are
not exposed through the system classloader.

[Stephan202]

I have one question as I fail to understand why. Why does this (not) happen?

However, when during a build the Java compiler loads
RefasterCheck, the templates on the annotation processor classpath are
not exposed through the system classloader.

There are short and long, simple and complex answers to this question, but the key point (IIUC) is that the system classloader loads only classes and resources on the "regular" classpath of the Java process. I think (but did not check) that this works at test time because Surefire creates new JVM processes with a classpath that matches the Maven test classpath. On the other hand, the annotation processor classpath is a special construct understood (and defined) only by the Maven Compiler Plugin, implemented using a custom classloader implementation; the system classloader is oblivious to that logic.