The new
[DuplicateBranches](https://errorprone.info/bugpattern/DuplicateBranches)
check caught some cases which I tried to comment out more clearly for
readability.

Just to stay up to date

… methods (#1473)

We should only update `targetCache` when computing the call graph, not
when reading its current state. When debugging another issue, I ran into
very confusing behavior where the debugger invoked `toString()` on a
`CHACallGraph` to display its state, which ended up updating
`targetCache` (whose state I was trying to debug) by calling an accessor
method.

- Remove a couple of `@Nullable` annotations and add `@Initializer`
instead, to better capture the protocol.
- Remove WALA's custom `@Initializer` annotation and use the one from
NullAway's annotations package, which we already depend on.

Fixes #1459 

To support lambdas, we re-use logic from the
`LambdaMethodTargetSelector` to handle calls that use `invokedynamic`.
`CHACallGraph` only includes edges for methods reachable from given
entrypoints, and our handling of lambdas adds new synthetic classes to
the class hierarchy (representing the classes generated for lambdas). So
to ensure a complete call graph, we do a second pass after adding these
synthetic classes to recompute call targets. This is probably not the
most efficient way to do things, but I'm not sure it's the bottleneck;
if we need to optimize in the future we should do so based on profiling.

Note that the handling of lambdas here is very imprecise; every call
site of a functional interface method will have an edge to every lambda
of that functional interface type. Still, it could be practically
useful, e.g., when combined with other heuristic filtering of irrelevant
code.

We add new tests, and also fix a couple other minor bugs (e.g., there
was no edge before to the synthetic method that invokes class
initializers, so it wasn't being processed properly).

---------

Co-authored-by: Ben Liblit <liblit@acm.org>