This reverts commit 6ab0efc.

Reverting the change since it causes a significant backward
compatibility break. Code like this previously worked as expected:

```
class C:
    def f(self, ...) -> None: pass

    g = f

C().g(...)  # Now sometimes generates an error
```

However, #10548 broke this in a subtle way (no error on definition,
it sometimes generates an error on call), and instead required the
introduction of a ClassVar annotation for `g`, which is non-intuitive
and error-prone. For example, some typeshed stubs use method
aliases such as the above (e.g. stubs for `logging`), and the change
broke those stubs. It's also arguably inconsistent, since normally
ClassVar annotations are optional.

Any fix to the original issue should avoid breaking method aliases
such as the above. Hopefully the fix can be adjusted suitably.

The PR may have broken incremental mode somehow as well -- cached
and uncached runs sometimes produce different results. The root
cause is still unclear, however.

…n#11571)

This reverts commit 6ab0efc.

Reverting the change since it causes a significant backward
compatibility break. Code like this previously worked as expected:

```
class C:
    def f(self, ...) -> None: pass

    g = f

C().g(...)  # Now sometimes generates an error
```

However, python#10548 broke this in a subtle way (no error on definition,
it sometimes generates an error on call), and instead required the 
introduction of a ClassVar annotation for `g`, which is non-intuitive 
and error-prone. For example, some typeshed stubs use method 
aliases such as the above (e.g. stubs for `logging`), and the change 
broke those stubs. It's also arguably inconsistent, since normally 
ClassVar annotations are optional.

Any fix to the original issue should avoid breaking method aliases
such as the above. Hopefully the fix can be adjusted suitably.

The PR may have broken incremental mode somehow as well -- cached
and uncached runs sometimes produce different results. The root
cause is still unclear, however.