analyzer: move strictCasts bool field out of TypeSystemImpl

[srawlins]

TypeSystemImpl was a convenient place to drop in the value of whether "strict casts" has been enabled in an analysis options file, but the treatment of those files is changing (an analysis options file will not be sufficient conditions to create an analysis context), so I think that field needs to move out of TypeSystemImpl. How is it used?

• A few error checkers query if (typeSystem.strictCasts) .... I think these queries can instead poke at the analysis options file which pertains to the library being analyzed.
• Inside TypeSystemImpl, the field is used in exactly one position: the isAssignableTo function, in order to disable all downcasts. We could instead make bool strictCasts a parameter on the function. But this function is referenced 59 times (at least?) in the Dart SDK, and they should probably all pass the correct value of strictCasts as per some library's analysis options file.

CC @scheglov @keertip @bwilkerson @pq .

[srawlins]

Alternatively, we can keep the field on TypeSystemImpl. Today we track which TypeSystemImpl should be used for a given analysis context. We would change that logic to track which TypeSystemImpl should be used for a given library.

This shouldn't require more instances of TypeSystemImpl running around. I think.

[bwilkerson]

We might have two instances where we had one before, but given that the only differences between instances is the value of a bool field we can't need more than two.

[srawlins]

(There actually two fields, I just filed this for strictCasts but there is also bool strictInference.)

I can't think of a case where we might have two instances where before we had one. If we had one before, then we had one analysis context, or maybe every analysis context had the same value for strict-casts. In those cases, we would still have one today. I guess what's important is that were not instantiating a TypeSystemImpl per library; still one per analysis-context-or-analysis-options-file.

[scheglov]

It might be convenient to continue encapsulating these flags inside a TypeSystemImpl, and just call methods like isSubtype or isAssignableTo and don't pass around additional set of flags. Think about a separate TypeSystemImpl as such set of flags. Obviously, this works well only if these a just boolean flags, and the number of instances is limited.

[srawlins]

I think Phil has been working on this.