Support TypeAliasType explicit call

[sobolevn]

The implementation turned out to be quite simple for the common cases.
Note: Right now there's no check that type_params= is correct, I am not sure that this is even required for a type-checker (in any case, this can and should be done in a follow-up PR)

Refs #16614

[sobolevn]

I will try to find how to fix typevar representation change without code modifications, I think that this has to do with my typing fixtures.

[github-actions]

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅

[tmke8]

One big advantage of X = TypeAliasType("X", ...) over X: TypeAlias = ... is that you can choose the order of the type parameters:

from typing import TypeVar
from typing_extensions import TypeAliasType

K = TypeVar("K")
V = TypeVar("V")

InvertedDict = TypeAliasType("InvertedDict", dict[K, V], type_params=(V, K))

def f(x: InvertedDict[int, str]) -> None:
    reveal_type(x)

pyright correctly reveals the type as dict[str, int] (i.e., inverted), but this branch reveals:

main.py:10: note: Revealed type is "builtins.dict[builtins.int, builtins.str]"

[JelleZijlstra]

I don't think we should claim support for TypeAliasType without checking the type_params. Explicit type_params are the main differentiating factor that sets the new syntax apart.

[hauntsaninja]

I'd be fine with this PR if we issue an error if type_params is provided

Also thanks for good detail spot tmke8!

[hamdanal]

Hello @sobolevn, I'd like to try and finish up this PR if that's OK with you.

[sobolevn]

@hamdanal please, go ahead :)
I forgot about it, sorry.

[JelleZijlstra]

Merged #16926 instead, thanks for your work here!