Improve collections.Counter stub

[AlexWaygood]

TwoThree changes:

1. RemoveChange the bad overload which the comment states is bad, and use a # type: ignore instead.
2. Improve Counter arithmetic dunders. Counter is halfway between a set and a dict, and the arithmetic dunders come from the set-like side of its personality. I think it makes sense to harmonise Counter's __sub__, __and__, __or__ and __add__ methods with the equivalent ones on typing.AbstractSet.
3. Use Counter[Any] instead of Counter[object] in various Counter dunders, due to dict invariance.

[Akuli]

I don't think we should change to Any, unless users complain. With Any, you won't get an error for counter_of_ints - counter_of_strings, which is bad IMO. With _T, you will get an error for counter_of_strings - counter_of_strings_or_nones, which apparently doesn't come up in practice because nobody has complained about it.

[AlexWaygood]

The same argument surely applies for Abstract Set.__sub__:

typeshed/stdlib/typing.pyi

Line 841 in c987c78

def __sub__(self, other: AbstractSet[Any]) -> AbstractSet[_T_co]: ...

Are we saying that in an ideal world, that also wouldn't be AbstractSet[Any], but it would probably be too disruptive to change it now?

[Akuli]

Changing AbstractSet would be more disruptive, but the argument doesn't apply to AbstractSet as much as it does to Counters:

• It's common to have sets that contain Nones and subtract between them, which I think is the most common use for subtracting sets of different types. I use sets containing Nones all the time.
• A counter that contains Nones would be something like {None: 2, "foo": 1, "bar": 6}, which seems like it could useful in some case but not very often. I don't remember ever using a counter like this, for example.

[AlexWaygood]

I'm still sorta unconvinced. I'll revert for now, and maybe open an issue to discuss in more depth later :)

[github-actions]

According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉