support bare/implicit type aliases

[carljm]

We already support simple cases of bare type aliases (e.g. MyInt = int) if they fall out correctly from evaluating the RHS as a value expression. But for more complex (and useful!) cases (e.g. MyType = int | str) we fail because we evaluate the RHS as a value expression and it needs to be evaluated as a type expression.

This requires some heuristics to decide what assignments should be treated as type aliases. (We should explore what other type checkers do here.)

It will also require a decision about how to handle the use of something we have decided is a type alias, in a value expression. Is this forbidden? Or do we need to have two types for that particular name, one value-expression type and one type-expression type?

[sharkdp]

Just for reference, we have existing support for non-generic PEP 695 type aliases: mdtests

[MichaReiser]

This might also require changes to the LSP (Goto type definition)

[carljm]

Here's a common implicit type alias case (from #275): https://play.ty.dev/1fa1c80b-f019-4d7d-8e59-80ad8e5fb2c4

from typing import Literal

HandleDupes = Literal["keep-first", "keep-last", "mean", None]

def test(handle_dup_idx: HandleDupes = None):
    if handle_dup_idx in ("keep-first", "keep-last"):
        # get possibly-unbound-attribute on next line
        reveal_type(handle_dup_idx)
    return None

We should know that the revealed type is Literal["keep-first", "keep-last"], and we do if a PEP 695 type alias is used, or if the HandleDupes type is inlined into the parameter annotation, but we don't understand the implicit type alias.