Introduce FluentFutureHandler as a workaround for Guava Futures/FluentFuture

[lazaroclapp]

We need this due to our incomplete support for generics, and the fact that #765 fixes a previous
false negative which would cause our @NonNull model for Guava's Function to be ignored
when determining the correct overriding of the functional interface by a lambda.

After the fix, however, code such as:

FluentFuture
            .from(...)
            .transform(s -> { if(...) {...} else { return null; } }, executor);

will fail with an error about Function::apply having a @NonNull result. Where nullability should
actually depend on the parameter T of the ListenableFuture<T> in question.

Unfortunately, usage of this futures API is common internally for us, and our generics support is far
from fully supporting this in a sound manner, so this diff introduces a (hopefully temporary) workaround,
in the form of handler for the Futures/FluentFuture Guava APIs:

This works by special casing the return nullability of com.google.common.base.Function and
com.google.common.util.concurrent.AsyncFunction to be e.g. Function<@Nullable T> whenever
these functional interfaces are implemented as a lambda expression passed to a list of specific
methods of com.google.common.util.concurrent.FluentFuture or
com.google.common.util.concurrent.Futures. This is unsound, but permits the code example above to
pass NullAway checking, while strictly reducing the safety hole of NullAway versions prior to PR #765.

[coveralls]

Pull Request Test Coverage Report for Build #1105

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 2 unchanged lines in 2 files lost coverage.
• Overall coverage increased (+0.03%) to 92.79%

---

Files with Coverage Reduction	New Missed Lines	%
../nullaway/src/main/java/com/uber/nullaway/dataflow/AccessPath.java	1	96.32%
../nullaway/src/main/java/com/uber/nullaway/handlers/Handlers.java	1	96.43%

Totals
Change from base Build #1104:	0.03%
Covered Lines:	5611
Relevant Lines:	6047

---

💛 - Coveralls

[msridhar]

One typo fix and this should be good to land. Approving assuming the typo will be fixed :-)

This is really a case where we need much deeper generics support, and we are just not there yet. Hopefully we can get closer soon.

I would ideally like to do perf benchmarking here, and I can't wait until #770 lands to make it easy! For now, based on reading the code I don't think it should have much perf impact, so we can go ahead and land.

[msridhar]

Suggested change

	private static boolean isGuavaFunctionDotAppy(Symbol.MethodSymbol methodSymbol) {
	private static boolean isGuavaFunctionDotApply(Symbol.MethodSymbol methodSymbol) {