Add autofix for flake8-type-checking

[charliermarsh]

Summary

This PR enables autofix for the most useful flake8-type-checking rules -- those that detect imports that are only used in type-checking contexts, and suggests that users move them into if TYPE_CHECKING: blocks. In the end, it's not a ton of code (most of this diff is tests + snapshots), but there's a large chain of changes that were required to support this.

The general flow is as follows. When we detect a typing-only import, we generate a new fixes, which consists of up to three edits: (1) an edit to remove the imported member from the import statement; (2) an edit to import TYPE_CHECKING from typing; and (3) an edit to add the imported member to the TYPE_CHECKING block, which could also require creating an entirely new TYPE_CHECKING block.

For example, given:

from __future__ import annotations

import pandas as pd

def f(x: pd.DataFrame):
    pass

We need to make all three of those changes, in order to get to:

from __future__ import annotations

from typing import TYPE_CHECKING

if TYPE_CHECKING:
    import pandas as pd

def f(x: pd.DataFrame):
    pass

The exact edit depends on the ordering and existence of the typing import, and/or the if TYPE_CHECKING blocks, and their positions relative to the first runtime usage -- but in typical usages, the edit looks something like the above.

Closes #2329.

Test Plan

• Ran cargo run -p ruff_cli -- check ../airflow --select TCH -n --fix; verified by eye that the edits looked reasonable and correct, and that there were no panics.
• Ran cargo run -p ruff_cli -- check ../rotki --select TCH -n --fix; verified by eye that the edits looked reasonable and correct, and that there were no panics.
• Ran cargo run -p ruff_cli -- check ../<project> --select TCH -n --fix over a few of my personal projects for which I have mypy setup, and verified that mypy passed without error before and after.

[charliermarsh]

(This is effectively the inverse of remove_imports, above.)

[charliermarsh]

Using LibCST here means we should generally retain comments.

[charliermarsh]

Note that we're generating an edit for every diagnostic, so we're generating an edit for every member in an StmtKind::ImportFrom statement. We may want to generate one edit for the entire statement, like we do for unused imports... But this does work correctly in practice. The main issue is that if you have:

from foo import bar, bar

Then after the fixes, we'll probably give you:

if TYPE_CHECKING:
    from foo import bar
    from foo import baz

These will get merged when you run the isort rules, so most users will never see this state (or will have it immediately corrected), but I guess it's not ideal (and it does mean that if you're using the LSP, you need to take one Code Action per member).

[charliermarsh]

The alternative, as hinted above, is that we generate one edit for the entire import statement. We may also want to then generate one diagnostic for the entire import statement? So this would take some refactoring.

[MichaReiser]

Merging the diagnostics on a per-statement level seems desirable to me but we can do this as a separate PR.

[MichaReiser]

This code looks (identical?) to your other PR. Is there an opportunity to share some of the logic?

[charliermarsh]

We have these everywhere that we do statement deletion :(

[MichaReiser]

Merging the diagnostics on a per-statement level seems desirable to me but we can do this as a separate PR.

[konstin]

nit: is there a reason why we have blank line after the top level import but not after the type checking block? (Seems to work everywhere but here anyway)

[konstin]

ecosystem ci looks good (https://gist.github.com/konstin/cf6f633a73a701bc94b089d2066e4675), most interesting case was https://github.com/apache/airflow/blob/27001a23718d6b8b5118eb130be84713af9a4477/airflow/models/__init__.py (module level __getattr__ with mypy)