We should probably deprecate DartType.operator== and DartType.hashCode

[stereotype441]

Analyzer clients currently use DartType.operator== (and potentially DartType.hashCode) to compare whether types are the same. This has several disadvantages:

• There different notions of what equality of types might mean (mutual subtyping, structural equality, structural equality ignoring the names of bound types, structural equality after normalization, structural equality after normalization but ignoring nullabilities). We've had to be careful in the analyzer to use the right kind of comparison in each case, and our clients are going to have to think about this too.
• In some cases a client might be using DartType.operator== and DartType.hashCode when some other technique is would be more appropriate, leading to subtle bugs (for instance, putting DartTypes into a set to detect infinite recursion; in many cases it's better to use elements for this purpose).
• The fact that clients use DartType.operator== complicates our ability to solve #40500.

It would be nice if we could deprecate the use of DartType.operator== and DartType.hashCode. Unfortunately we don't have a good way to statically find uses of these. We would have to do something like change their implementations to throw an exception (in a breaking change release of the analyzer, after a suitable warning period), and then use experimental rolls into the internal codebase to detect all clients that need to be fixed.

[stereotype441]

Another idea: to help clients find places where they use DartType.operator== and DartType.hashCode, we could have a static boolean to control whether they throw an exception. Once a client has stopped using the deprecated logic, it could set the boolean in its tests, to make sure it doesn't accidentally regress later. We could mark the boolean as @visibleForTesting to avoid accidental misuse.

Once all clients have been fixed, we would hardcode the boolean to true (in a breaking change release of the analyzer).