[pylint] Don't recommend decorating staticmethods with @singledispatch (PLE1519, PLE1520)

[alex-700]

…andling

Summary

Fixes #10619

The behaviour, introduced in this PR, is different from original pylint's one, but this one is more natural.

According to the docs of staticmethod, the method marked with @staticmethod can be called via class (C.foo()) and via the instance (C().foo() (UFCS: C.foo(C())). Marking such method with @singledispatch allows only call via class, but not via the instance. Marking such method with @singledispatchmethod supports both C.foo() and C().foo(). The latter also is supported by singledispatchmethod docs via

@singledispatchmethod supports nesting with other decorators such as @classmethod.
...
The same pattern can be used for other similar decorators: @staticmethod, @abstractmethod, and others.

Example

class C:
    @singledispatchmethod
    @staticmethod
    def foo(x): raise NotImplementedError()

    @foo.register
    @staticmethod
    def _(x: int) -> int: return x


print(C.foo(1))
print(C().foo(1))

prints

1
1

but

class C:
    @singledispatch
    @staticmethod
    def foo(x): raise NotImplementedError()

    @foo.register
    @staticmethod
    def _(x: int) -> int: return x


print(C.foo(1))
print(C().foo(1))

fails with

C.foo() takes 1 positional argument but 2 were given

Test Plan

cargo test

[github-actions]

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

[AlexWaygood]

Thanks @alex-700!