Add help: subdiagnostics for several Ruff rules that can sometimes appear to disagree with ty

[AlexWaygood]

Summary

Ruff has a bunch of rules that can sometimes appear to disagree with ty. For example, this snippet of code will trigger an FBT001 violation:

# third-party file somewhere...

class Foo:
    def f(self, x: bool): ...

# first-party code...

class Bar(Foo):
    def f(self, x: bool): ...

But the author of this code can't change the definition of Foo.f (because it's third-party code), and they can't change Bar.f or ty will complain about a violation of the Liskov Substitution Principle.

We've already added documentation notes to a bunch of these rules in #21644 that tell people to use typing.override in this situation. Ruff will generally ignore this kind of rule if it sees that the method is decorated with @override, because it knows that a user can't easily change an @override-decorated rule without violating the Liskov Substitution Principle. However, we've still received some reports from users who are understandably confused about two Astral tools seeming to give contradictory orders about how the user should rewrite their code.

This PR adds help: subdiagnostics to several Ruff rules. The subdiagnostics also point the user towards typing.override; having the hint directly presented in the terminal should be more approachable and harder to miss.

Test Plan

Snapshots updated.

[astral-sh-bot]

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

[AlexWaygood]

(There are a couple more rules that can cause issues with a type checker's Liskov enforcement. I basically just added help: subdiagnostics to the ones where it was easy to do so.)

[ntBre]

Makes sense to me, thanks!

[ntBre]

I kind of prefer this phrasing over the LSP version, but I don't feel strongly. I'm guessing we can't call the helper function here because the current scope isn't set?

[AlexWaygood]

I'm guessing we can't call the helper function here because the current scope isn't set?

That wasn't really my rationale for doing something slightly different here. The reasons why I did something slightly different here is that this violation is telling you to rename the function rather than change its signature, and renaming the function isn't going to cause a Liskov violation. It's just not necessarily what you want to do if the function is deliberately overriding something from a subclass 😄

[ntBre]

Can we use the helper here? Oh, I see it's an FBT helper.

[AlexWaygood]

Right — I could put the helper somewhere more central, but wasn't totally sure where a good place would be :/