[flake8-pyi] Fix PYI041 not resolving string annotations

[robsdedude]

Summary

While working on #18637, I noticed that PYI041 does not properly resolve string annotations. This PR fixes that.

Test Plan

A whole new file with tests has been added.

[github-actions]

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

[MichaReiser]

Can you add a test for a type annotation consisting of a concatenated string literal:

Suggested change

	def good1(arg: "int") -> "int | bool":
	...
	def good1(arg: "int") -> "int" "| bool":
	...

[robsdedude]

Good catch! While detection works, the fix did indeed drop the quotation marks.

[robsdedude]

This is non-trivial to fix. I'll have to go on a side-mission fixing #19184 first.

My approach was to alter parse_simple_type_annotation (just like parse_complex_type_annotation already does) such that the resulting resolved virtual expression spans that whole string. That way, the rule can just replace the whole string and wrap it in quotes if the original annotation was a forward reference.

But alas, that change to parse_simple_type_annotation amplifies the linked bug to also affect non-concatenated forward refs.

[MichaReiser]

I believe this was part of the reason why we decided not to support string annotations in the initial implementation as they aren't as common anymore and we didn't felt like they're worth all the complexity they add.

Could we disable the fix for problematic stringified annotations (I think you can also use triple quoted strings or put them across multiple lines). We should try to add tests for all of those if we decide that supporting them is worth the complexity

[robsdedude]

Tripple quoted type annotations actually work fine. There are some in the test set.

[robsdedude]

I ended up addressing this in a similar way as RUF013 handles is:

• analysis on stringized annotations: will do
• suggesting fixes on stringized annotations: only if simple sting (i.e., non-concatendated) and always mark as unsafe.

[ntBre]

Thanks and sorry for the delay. This looks good to me, but I think we may need to gate this behind preview since it's a pretty big change to a stable rule.

Otherwise I just had some small ideas/suggestions, assuming @MichaReiser's concerns are resolved.

[robsdedude]

@ntBre @MichaReiser Could you have another look. I think I addressed all comments.

Note to myself: when this is merged, take another look at #19184 to see if the same approach (#19023 (comment)) could be applied.