Fixes #1091

Consider the following code:

abstract class Test {
  abstract <V> @Nullable V foo(Function<@Nullable V, @Nullable V> f);
  void testPositive(Function<String, String> f) {
     this.<String>foo(f); // error
  }
} 

The call to foo should not type check. Since the type of its parameter f is Function<@Nullable V, @Nullable V>, with explicit @Nullable annotations on the type variables, any Function passed to foo must have @Nullable type arguments. In typechecking this code, NullAway previously substituted the type arguments for the type variables in foo just using built-in javac routines. But, this would yield a formal parameter type Function<String, String>, as the javac routine would not retain the explicit type arguments in the right places. So we would miss reporting an error. This PR fixes the substitutions and re-introduces the annotations on type variables, so we get the type Function<@Nullable String, @Nullable String> for the formal parameter at the call, and report an error correctly. Substitutions were broken in other cases as well; substituting @Nullable V for @Nullable V (where V is a type variable) yielded just V, which led to false positives (like #1091).

The main logic changes are in TypeSubstitutionUtils. We add a new RestoreNullnessAnnotationsVisitor and use it to restore nullability annotations from type variables after performing a substitution.

We also extract the TypeMetadataBuilder logic to a top-level source file, and add new methods as needed for this PR. Some of this could have been split into a separate PR but it's a bit of a pain to extract it now.