Fixes #13536

Fixes #5018 
Fixes #5439
Fixes #10850 

The implementation is simple but not the most beautiful one. I simply add a new slot to the `Instance` class that represents content of the module. This new attribute is short lived (it is not serialized, and not even stored on variables etc., because we erase it in `copy_modified()`). We don't need to store it, because all the information we need is already available in `MypyFile` node. We just need the new attribute to communicate between the checker and `subtypes.py`.

Other possible alternatives like introducing new dedicated `ModuleType`, or passing the symbol tables to `subtypes.py` both look way to complicated. Another argument in favor of this new slot is it could be useful for other things, like `hasattr()` support and ad hoc callable attributes (btw I am already working on the former).

Note there is one important limitation: since we don't store the module information, we can't support module objects stored in nested positions, like `self.mods = (foo, bar)` and then `accepts_protocol(self.mods[0])`. We only support variables (name expressions) and direct instance, class, or module attributes (see tests). I think this will cover 99% of possible use-cases.

This pull request:

1.  Fixes #8334. Overriding a dataclass attribute with a method or
    property now results in an error message, not a crash.

    (Overriding an attribute with a non-attribute at runtime will
    result in either inconsistent behavior or an exception, so
    I think unconditionally disallowing this is fine.)

2.  Makes mypy report an error if you try subclassing a frozen
    dataclass with a non-frozen one or vice versa. Attempting to
    do this subclassing at runtime will raise a TypeError.

During the error handling transform we have access to always
defined attributes, which allows us to infer that certain
attribute operations will never fail.

This can improve performance and reduce the size of the generated
code.

Fixes #10090 

Unfortunately we cannot fully support this use case. Mypy requires explicit type annotations to generate methods for dataclasses before type checking. While type inference for bare `Final` happens during type checking. I still try to infer type if the default is a literal, otherwise give an error, and use `Any` for generated methods.

Per-module error codes were added in #13502, let's recommend using them.

The existing type ignore behaviour is pretty unintuitive; I think most
people actually want `# mypy: ignore-errors`. There are probably people
depending on the current behaviour though.

Fixes #13435, fixes #12076, fixes #11999, fixes #11027, fixes #9318,
fixes #7839

Fixes #6801
Fixes #10577
Fixes #12642
Fixes #12337
Fixes #10639 
Fixes #13390 

All these crashes are in a sense duplicates of each other. Fix is trivial, except I decided to ban type aliases in protocol bodies. Already in the examples in issues, I have found two cases where people wrote `foo = list[str]`, where they clearly wanted `foo: list[str]`. This can cause hard to spot false negatives.

This might slightly improve performance when using native ints,
and it's consistent with how other error handler branches are
treated as rare.

Now the generated error handling code when calling a function
that returns a native int looks something like this (the
`unlikely(...)` part is new):

```
    cpy_r_r0 = CPyDef_f();
    cpy_r_r1 = cpy_r_r0 == -113;
    if (unlikely(cpy_r_r1)) goto CPyL2;
```

Fixes #13521

Basic support for arithmetic, bitwise and comparison ops using native
int types i32 and i64. Also support some implicit coercions between
int and native int types. There are still various gaps in the functionality,
and that's why the feature is test-only so far.

Division and modulus ops require jumping through some hoops to make
the behavior with negative operands match Python semantics.

This can already show some improvements in benchmarks (using hacks
these can be used outside tests). I'll post figures once the implementation
is more complete.

Work on mypyc/mypyc#837.

These are somewhat buggy and modern per-module options should be
preferred. I can't find any use of strict_optional_whitelist.
There is some use of show_none_errors, but it's all set to True;
I think people are just worried and cargo culting and want mypy to
really, actually give them all the errors.

Fixes #6514, fixes #2396

I forgot to add this to yesterdays PR #13501

Fixes #9440

This is a bit non-trivial because I decided to make per-module code act as overrides over main section error codes. This looks more natural no me, rather that putting an adjusted list in each section.

I also fix the inline `# mypy: ...` comment error codes, that are currently just ignored. The logic is naturally like this:
* Command line and/or config main section set global codes
* Config sections _adjust_ them per glob/module
* Inline comments adjust them again

So one can e.g. enable code globally, disable it for all tests in config, and then re-enable locally by an inline comment.

Fixes #12241

The code involved is really old. The mentioned test case does not
trigger any errors. I cannot find any mention of this error message in
any non-ancient mypy issues

Blocking errors are a bad user experience and there's no reason for this
one to be one / there is another code path for invalid type ignores that
is non-blocking.

Fixes half of #12299. The half it doesn't fix is that ideally users
shouldn't be getting these warnings from third party libraries.
Also see #12162 (comment)
But that's for another PR

Fixes #4536

This use case is specified by PEP 544 but was not implemented. Only instances (not class objects) were allowed as protocol implementations. The PR is quite straightforward, essentially I just pass a `class_obj` flag everywhere to know whether we need or not to bind self in a method.

Fixes #13499

Today this code reads like "stubs should all target 3.7" and this
is indeed how typeshed operates. But authors of pyi other than typeshed
should probably be allowed to choose what Python version they're
targetting. Since typeshed runs checks against 3.7, this should not
cause testing regressions for typeshed.

This code goes back to #3000 back in the typed_ast days, when this
allowed stubs to use much newer syntax features than the base Python
version, so in some ways this is in the spirit of the original code.

Fixes #6393

This is unspecified behavior in terms of PEP 544, so we just try to 
do something meaningful (see test case). At least we should not crash.

Fixes #13226

Fixes #9282 

It looks like `super()` checking is too strict for methods with self-types. Mypy explicitly allows self-type annotation to be a supertype of current class, so to be consistent, I relax the check for `super()` as well.

Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>