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.