Fix bug where methods defined using lambdas were flagged by FURB118

[AlexWaygood]

Summary

Fixes #13829.

Replacing an instance method definition with an operator-module function doesn't work, because instance methods need to be callable objects with __get__ methods ("descriptors"), and while user-defined functions are descriptors, this is not true for the operator-module functions. We already avoid flagging user-defined methods that are defined using def statements, but we currently incorrectly flag user-defined functions that are defined by assigning lambdas to variables in class bodies. I.e., this is a perfectly valid definition of an instance method, and FURB118's suggestion to replace the lambda with operator.eq function would break it:

class Spam:
    foo = lambda self, other: self == other

As a demonstration in the REPL:

>>> class Spam:
...     foo = lambda self, other: self == other
...     
>>> Spam().foo(Spam())
False
>>> from operator import eq
>>> class Spam:
...     foo = eq
...     
>>> Spam().foo(Spam())
Traceback (most recent call last):
  File "<python-input-4>", line 1, in <module>
    Spam().foo(Spam())
    ~~~~~~~~~~^^^^^^^^
TypeError: eq expected 2 arguments, got 1

This PR fixes things so that lambda assignments in class bodies are considered off-limits for the rule in the same way as def statements in class bodies. It also makes the fix-safety docs more expansive, so that they're clearer that there's a wider range of reasons why the rule might be unsafe than just the keyword-argument issue.

Test Plan

I added a new fixture that confirms that all function definitions in class bodies are ignored by the rule.

[github-actions]

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

ℹ️ ecosystem check detected linter changes. (+0 -1 violations, +0 -0 fixes in 1 projects; 54 projects unchanged)

zulip/zulip (+0 -1 violations, +0 -0 fixes)

ruff check --no-cache --exit-zero --ignore RUF9 --output-format concise --preview --select ALL

- zerver/models/custom_profile_fields.py:131:81: FURB118 Use `operator.itemgetter(1)` instead of defining a lambda

Changes by rule (1 rules affected)

code	total	+ violation	- violation	+ fix	- fix
FURB118	1	0	1	0	0

[AlexWaygood]

Hmm, the airflow hits in the ecosystem check are false negatives. I think I can avoid them.

[AlexWaygood]

This needed to be moved from deferred_lambdas.rs to expressions.rs because otherwise the semantic model doesn't understand that the lambda it's analysing is ever inside a class scope. As far as I can tell, there's no particular advantage associated with deferring the analysis of this rule to after the semantic model has been fully built (what we currently do). The rule never analyses any bindings or uses of bindings

[MichaReiser]

Thanks for writing this comment. It saved me quiet some time guessing why it was moved.

[AlexWaygood]

it took me a little while to figure out why the semantic model didn't think lambdas inside class scopes were inside class scopes 😅

[AlexWaygood]

7e13565 got rid of the new false negatives this PR initially introduced on airflow. The remaining ecosystem hit on zerver is also a false negative introduced by this PR, but I think it's acceptable personally. Flagging lambdas inside assignments in class scopes is too risky.

[MichaReiser]

Thank you

[MichaReiser]

Thanks for writing this comment. It saved me quiet some time guessing why it was moved.