Fixes #16450

The fix is a bit ad-hoc, but OTOH there is nothing meaningful we can
infer in such situation, so it is probably OK.

Fixes #16451

This special-casing is unfortunate, but this is the best I came up so
far.

Fixes #9910
Fixes #16452

We already exclude private names from override type compatibility checks
etc., but it looks like some override checks were still performed, we
need to skip them, since private name is actually a different name in
subclass.

---------

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

Fixes #16468

The fix is straightforward.

Btw when fixing this I noticed that we disregard type arguments when
narrowing, for example:
```python
x: Sequence[int]
if isinstance(x, tuple):
    reveal_type(x)  # tuple[Any, ...], but should be `tuple[int, ...]`
```
I guess fixing this may be tricky, and it is quite old behavior.

Fixes #16405
Fixes #16412

Imprecise argument kinds inference was added a while ago to support
various edge cases with `ParamSpec`. This feature required mapping
actual kinds to formal kinds, which is in general undecidable. At that
time we decided to not add much special-casing, and wait for some real
use-cases. So far there are two relevant issues, and it looks like both
of them can be fixed with simple special-casing: ignore argument
positions in subtyping if arguments can be matched by name. This adds
minor unsafety, and generally doesn't look bad, so I think we should go
ahead with it.

---------

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

Fixes #16473

Potentially we can turn this helper function into a proper visitor, but
I don't think it is worth it as of right now.

---------

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

Fixes #16512

The problems were caused if same callback protocol appeared multiple
times in a signature. Previous logic confused this with a recursive
callback protocol.

Fixes #16480

Fix is straightforward, but also suspicious, since I am not sure how it
ever worked without this.