Defer type analysis of integer Literal when builtins.int is slow to resolve

[tungol]

This MR fixes two possible crashes related to builtins.int not being ready yet when a Literal is analyzed. One happens if builtins.int is entirely unavailable, and the other if builtins.int is only available as a placeholder node.

The first case is responsible for the crash if typeshed imports Literal from typing instead of typing_extensions. Mypy has Literal available during the first pass of builtins.pyi, which means it encounters Literal[0] before it's seen the class int statement: python/typeshed#11247

The second case occurs if builtins.int is a subclass of something that's slow to resolve, which turns up if you try to make builtins.int inherit from numbers.Integral: python/typeshed#12894

Both cases are resolved by deferring during TypeAnalyser.analyze_literal_param if the type of the literal isn't ready yet.

After fixing those, an additional issue became apparent, where the r.h.s of a TypeAlias assignment is ready but TypeAlias itself isn't ready yet, which caused mypy to say it wasn't a valid TypeAlias. An additional check and defer within SemanticAnalyzer.visit_assignment_stmt fixes that. This didn't happen before because typing_extensions.Literal and typing_extensions.TypeAlias resolved at the same speed, so it wasn't noticeable. Some problems shows up for deferred on any unresolved lhs type, so I restricted it to only defer for unresolved lhs types which were imported from typing or typing_extensions.

[github-actions]

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