Add support for Preconditions.checkArgument through custom CFG translation

[lazaroclapp]

See #47 for discussion.

This PR adds support for Preconditions.checkArgument(...) and Preconditions.checkState(...)
throw a new PreconditionsHandler handler.

In order to implement said handler, we need a custom CFG translation pipeline in NullAway
(NullAwayCFGBuilder) which subclasses the Checker Framework's CFGBuilder
(which we were using directly before this change). This pipeline allows us to add handler
callbacks during the AST to CFG translation process. At the moment, we add a single
such callback, right after visiting a MethodInvocationTree. We also add a more or less
generic method to insert a conditional jump and a throw based on a given boolean expression
node.

Abstracting some details about our AST and CFG structures, we translate:

Preconditions.checkArgument($someBoolExpr[, $someString]);

Into something resembling:

Preconditions.checkArgument($someBoolExpr[, $someString]);
if ($someBoolExpr) {
   throw new IllegalArgumentException();
}

Note that this causes $someBoolExpr to be evaluated twice. This is necessary based on how
NullAway evaluates branch conditionals, since we currently do not track boolean values through
our dataflow (e.g. boolean b = (o == null); if (b) { throw [...] }; o.toString(); produces a dereference
according to NullAway, independent on whether that code was added by rewriting or directly on the
source.

That said, note that obviously this doesn't change the code being compiled or bytecode being produced,
the rewrite is only ever used by/visible to NullAway itself.

Finally, our implementation of NullAwayCFGBuilder and particularly NullAwayCFGTranslationPhaseOne
in this PR, depend on a Checker Framework APIs that are currently private. We are simultaneously
submitting a PR to change the visibility of these APIs (see CheckerFramework#5156)

[lazaroclapp]

Important: This will not build (and shouldn't land) until the corresponding CF PR is landed and a new CF version cut.

[lazaroclapp]

TODO: Change before landing, but after CF has cut a new release.

[msridhar]

FWIW, overall this approach looks fine to me!

[msridhar]

I pulled in today's CF release. Did not do all the other relevant cleanup (like removing mavenLocal())

[coveralls]

Pull Request Test Coverage Report for Build #873

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 6 unchanged lines in 3 files lost coverage.
• Overall coverage increased (+0.05%) to 92.131%

---

Files with Coverage Reduction	New Missed Lines	%
../nullaway/src/main/java/com/uber/nullaway/handlers/Handler.java	1	91.67%
../nullaway/src/main/java/com/uber/nullaway/handlers/Handlers.java	1	96.55%
../nullaway/src/main/java/com/uber/nullaway/dataflow/DataFlow.java	4	95.45%

Totals
Change from base Build #872:	0.05%
Covered Lines:	4824
Relevant Lines:	5236

---

💛 - Coveralls

[lazaroclapp]

I pulled in today's CF release. Did not do all the other relevant cleanup (like removing mavenLocal())

Let's do this the slightly slower but more CHANGELOG friendly way: #610 😉

[msridhar]

I ran our benchmarks before and after this PR and saw no increase in NullAway overhead; so this change seems to be safe from that standpoint.

[msridhar]

@lazaroclapp ping me when this is ready for a full review

[msridhar]

LGTM, this is great!