Add --no-implicit-dynamic flag to strong mode

[jmesserly]

forked from #24267, also see: dart-archive/dev_compiler#299, dart-archive/dev_compiler#363, dart-archive/dev_compiler#365

[jmesserly]

Taking a look at this.

[jmesserly]

Note this will include implicit dynamic in a type argument to a class/typedef/generic function/generic method.

[jmesserly]

implemented in https://codereview.chromium.org/2093523002/. I sent to @leafpetersen to see if the design seems right. There's a lot more nuance than I'd thought at first. In particular, how to handle implicit generic types used as type annotations. But there are some other interesting cases too, like the return type of a function expression.

[jmesserly]

So what we're brainstorming now is a set of flags as we gather data:

• no-implicit-dynamic: roughly what the CL does.
• no-implicit-casts: mostly implemented, see #26583
• no-inferred-dynamic: any position where a type could be inferred, report if inference fails. Inference here includes downward inference and variable initialization, TBD other cases like [42 as dynamic], see #26781
• no-implicit-generic-types: disallow using C to stand for C<dynamic>. TBD if C means C<Object> or is an error, see #26784

No current plans to implement these, but for completeness, here are some other ideas that have floated around:

• no-reified-dynamic: fairly similar to no-implicit-dynamic, but would also reject explicit dynamic in reified positions (type arguments). TBD if this uses implicit-Object. Benefit unclear in a strong mode world (Object and dynamic are practically the same at runtime in strong mode).
• no-dynamic: disallows dynamic entirely in the Analyzed code. TBD if this uses implicit-Object. The goal would be to guarantee no nSMs in the analyzed code.
• implicit-object: use Object for missing types.

[jmesserly]

CC @leafpetersen @munificent -- see above for my notes on the various flags we may want.