Add optional error code for legacy type comments

[cdce8p]

Ref #12947

[emmatyping]

I think if we are going to deprecate type comments we will absolutely need to provide a switch to let folks silence this message. Based on the primer output, it seems (expectedly) that the usage of type comments are pervasive in some code bases. These code bases should be allowed to ignore this deprecation for now. I also think if we are going to deprecate type comments loudly we should link from the deprecation message to a page in the documentation about how to migrate a codebase using type comments to annotations automatically (or at least, mostly automatically). This page should mention things like the libcst codemod https://libcst.readthedocs.io/en/latest/codemods.html#libcst.codemod.visitors.ApplyTypeAnnotationsVisitor

[JukkaL]

We should probably start with a new opt-in error code about type comments and explaining that we are planning to (soft) deprecate type comments eventually.

I'm working on a new parser for mypy and it doesn't yet fully support type comments, but it may be worth it to continue to support them still in the future, if many old type comments are still around. I think I can add full support for type comments to the new parser, it's just some extra work.

We might require some flag to even parse type comments at some point, but this would be a backward compatibility break.

[hauntsaninja]

I am fine with opt-in errors, but strongly against on-by-default errors for this. I think there are ways we can spend our churn budget that are better for users.

Happy to help with parser work (including adding support for type comments)!

[JukkaL]

The new parser is being developed here: https://github.com/mypyc/ast_serialize

[github-actions]

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅

[JukkaL]

Could we make this work with the new parser, for the kinds of type comments the new parser supports? The new parser supports function and variable type comments, but not for loop or with statement type comments. For loop and with statements type comments are likely just a tiny fraction of all type comments.

If we can't make this work at all with the native parser, can you generate an error message suggesting the use of --no-native-parser? Also add a test case that uses the native parser.