Disallow calling type on Protocol

[hauntsaninja]

Fixes #16919, fixes #16890

It's possible we should not issue the diagnostic and only return object, but that may confuse users. Let's see the primer. Now trying just returning type | types.ModuleType | Any

Should also probably disallow type[P] as well.

[github-actions]

Diff from mypy_primer, showing the effect of this PR on open source code:

websockets (https://github.com/aaugustin/websockets)
+ src/websockets/legacy/protocol.py:683: error: Item "type" of "type | Module | Any" has no attribute "__aiter__" (not async iterable)  [union-attr]
+ src/websockets/legacy/protocol.py:690: error: Item "type" of "type | Module | Any" has no attribute "__anext__"  [union-attr]

scrapy (https://github.com/scrapy/scrapy)
+ scrapy/utils/python.py:311: error: Unused "type: ignore" comment  [unused-ignore]
+ scrapy/utils/python.py:311: error: Module not callable  [operator]
+ scrapy/utils/python.py:311: note: Error code "operator" not covered by "type: ignore" comment

hydra-zen (https://github.com/mit-ll-responsible-ai/hydra-zen)
+ src/hydra_zen/structured_configs/_implementations.py:1117: error: Argument 1 to "signature" has incompatible type "type | Module | Any"; expected "Callable[..., Any]"  [arg-type]
- src/hydra_zen/structured_configs/_implementations.py:1137: error: No overload variant of "builds" of "BuildsFn" matches argument types "type[DataclassInstance]", "dict[str, int | float | Path | DataClass_ | type[DataClass_] | ListConfig | DictConfig | Enum | Sequence[HydraSupportedType] | Mapping[Any, HydraSupportedType] | None]", "bool | None", "Literal['none', 'partial', 'all', 'object'] | None", "DataclassOptions"  [call-overload]
+ src/hydra_zen/structured_configs/_implementations.py:1137: error: No overload variant of "builds" of "BuildsFn" matches argument types "type | Module | Any", "dict[str, int | float | Path | DataClass_ | type[DataClass_] | ListConfig | DictConfig | Enum | Sequence[HydraSupportedType] | Mapping[Any, HydraSupportedType] | None]", "bool | None", "Literal['none', 'partial', 'all', 'object'] | None", "DataclassOptions"  [call-overload]

xarray-dataclasses (https://github.com/astropenguin/xarray-dataclasses)
+ xarray_dataclasses/datamodel.py:214: error: Incompatible types in assignment (expression has type "type | Module | Any", variable has type "type[DataClass[PInit]] | DataClass[PInit]")  [assignment]
+ xarray_dataclasses/datamodel.py:216: error: Argument 1 to "get_type_hints" has incompatible type "type[DataClass[PInit]] | DataClass[PInit]"; expected "Callable[..., Any]"  [arg-type]

antidote (https://github.com/Finistere/antidote)
+ src/antidote/lib/interface_ext/_internal.py:171: error: Argument 1 to "setdefault" of "MutableMapping" has incompatible type "type | Module | Any"; expected "type[PredicateConstraint[Any]]"  [arg-type]
+ src/antidote/lib/interface_ext/_internal.py:172: error: Argument 1 to "issubclass" has incompatible type "type | Module | Any"; expected "type"  [arg-type]
+ src/antidote/lib/interface_ext/_internal.py:173: error: Unused "type: ignore" comment  [unused-ignore]

[JukkaL]

The websockets error is an interesting one:

        elif isinstance(message, AsyncIterable):
            ... type(message).__aiter__ ...

This is kind of reasonable, since modules can't really implement __aiter__.

Maybe we could infer that protocols with certain dunder methods can only be implemented by regular class instances, and fall back to the to the old type(x) behavior? This would imply that a module object, for example, can never be assignable to AsyncIterable.