JSpecify: initial checks for generic type compatibility at assignments

[NikitaAware]

This pull request adds the identical type parameter nullability checks for both sides of an assignment.
for example
NullableTypeParam<@Nullable String> nullableTypeParam = new NullableTypeParam<String>(); should generate an error as the type parameters of both sides of the assignment do not have the same Nullability annotations.
This PR covers the following cases:

• checks for the variable instantiation A<String> a = new A<@Nullable String>();
• checks for the assignments
  A<@Nullable String> t1 = new A<@Nullable String>(); A<String> t2; t2 = t1;
• LHS and RHS with the exact same types
  A<String> a = new A<@Nullable String>();
• RHS being a subtype of LHS

class Test {
  class D<P extends @Nullable Object> {}
  class B<P extends @Nullable Object> extends D<P>{}
  void test1() {
      // BUG: Diagnostic contains: Cannot assign from type
      D<String> f = new B<@Nullable String>();
  }
}

• nested generics
  A<B<String>, String> a = new A<B<@Nullable String>>();

The PR does not handle pseudo-assignments due to parameter passing / returns; that support will come in a follow-up PR. Also note that this PR only changes NullAway behavior when JSpecifyMode is enabled.

[msridhar]

I may tweak the lambda and diamond operator test cases to be a bit clearer

This is now done. To summarize, we don't seem to crash for lambdas / method refs / diamond operators, but (unsurprisingly) we miss some bugs.

[lazaroclapp]

Very minor nits remaining! Looks fine to land to me once those are addressed! 🎉

[lazaroclapp]

There are two comments on the tests that should also start with // TODO. That said, other than that, this PR LGTM. @msridhar, if this ok by you, we could make the edits in the UI and land (or wait for @NikitaAware to make the edit, either works for me)!

[lazaroclapp]

Cool! Should land automatically once CI passes. Again, thanks for all the great work @NikitaAware 🎉 !