enhance `prefer_const_literals_to_create_immutables` to lint constructor tear-off invocations

[pq]

Test case:

@immutable
class A {
  const A(a);
}

void constructorTearOffs() {
  var makeA = A.new;
  var l1 = makeA([]); // LINT
  var l2 = makeA(const[]); // OK
}

[pq]

This may be hard. Essentially it depends on knowing that a given FunctionExpressionInvocation corresponds to a constructor tear-off and not just a Function and chatting w/ @scheglov, it sounds like this is not generally tracked (and could only be discovered in the most local cases which seem, in practice, pretty unlikely to occur.

My gut is this is a wait and see. If folks find themselves missing this when constructor tear-offs get adopted, we can look closer at possible solutions.

[pq]

FWIW, this limitation affects other lints that care about constructor invocations too.

For example:

• use_full_hex_values_for_flutter_colors
• use_key_in_widget_constructors

etc.

(Of course what extent any of this matters depends on how folks use the feature... we'll see!)

[bwilkerson]

Agreed. And even if it were possible in some cases it wouldn't be possible in all cases. Consider

void add(String name, Object Function() constructor) {
  table[name] = constructor();
}

Different constructors might well be passed in at different call sites, or non-constructors for that matter. Any checking we'd do based on the assumption that it was a specific constructor, or from a class with a specific annotation, would be highly suspect.

There will always be ways for users to subvert checks (dynamic for instance). I don't think we need to worry too much about constructor tear-offs adding one more such way.