CFE allows implicit tear-offs on nullable receivers

[leafpetersen]

The CFE currently allows an implicit call method tear-off even when the receiver of the implicit tear-off is a nullable type:

class C {
  int call() => 0;
}

void main() {
  int Function() c0 = (null as C?);   // Should be an error
  int Function()? c1 = (null as C?); // Should be an error
  print(c0);
  print(c1);
}

Note that the first line is simply unsound. Both statements seem to evaluate to null.

For reference, I am proposing the following addition to the NNBD spec to cover this:

The implicit tear-off conversion which converts uses of instances of classes
with call methods to the tear-off of their `.call` method when the context type
is a function type is performed when the context type is a function type, or the
nullable version of a function type.  

Implicit tear-off conversion is *not* performed on objects of nullable type,
regardless of the context type. 

cc @stefantsov @johnniwinther

[lrhn]

Accepting a nullable function type as context type for doing tear-off suggests that we should also consider FutureOr<functionType>, as the other union type.

Maybe the rule can be reduced to:

If the static type T of an expression is not assignable to its context type, but T is a callable object type with a call method function type F s.t. F is assignable to T, then implicitly tear off the call method.

So if the context type is a union type, and the expression type is not assignable to the context type, but the expression type is precisely a callable object type, and the function type of the callable object is assignable to the union type, then at least one of the types of the union must be a function type or Function (because the only types that functions types are assignable to are Function, function types, top types and bottom types, and the last one only as long as we have implicit downcasts. The original type would be assignable to the top type, so there must be a function type in there that we are assigning to).

This then covers functionType? and FutureOr<functionType> and FutureOr<functionType?>?, and will be compatible with general union types, should we ever get them.

(No argument that we should not do tear-offs on nullable types, even if we could using ?.).

[chloestefantsova]

Proposed fix: https://dart-review.googlesource.com/c/sdk/+/133982