Support locally scoped type alias nodes

We mentioned this at a previous design meeting while discussing conditional types but I don't think an issue was opened for it (nor can I find mention of it within some design meeting notes). We think it'd be useful for both conditional types (to make a bare type reference/parameter) and in complex types (to reduce duplication) to enable a kind of type-alias-as-a-type-node syntax. Something that allows rewriting code like this:

type Foo<T, K extends string, TVal extends T[K] = T[K]> = TVal extends string ? {x: TVal} : never;

as

type Foo<T, K extends string> = type TVal = T[K] in TVal extends string ? {x: TVal} : never;

or

type MyBox<T, K extends keyof T = keyof T, TVal extends T[K] = T[K]> = {
  host: T,
  getValue(k: K): TVal,
  setValue(k: K, v: TVal): TVal
};

as

type MyBox<T> = type K = keyof T, TVal = T[K] in {
  host: T,
  getValue(k: K): TVal,
  setValue(k: K, v: TVal): TVal
};

this allows elision of unnecessary information (no need to write both a constraint and identical default), and prevents usages from accidentally providing an extra type parameter when they shouldn't (because the defaulted parameter was used effectively as a const). I believe @bterlson had mentioned wanting something like this in-person, too.

As for proposed syntax, I'd say:

• A LocalTypeAlias is a TypeNode (so is valid anywhere a TypeNode is).
• A LocalTypeAlias is parsed as a required type keword, then a comma separated list of LocalTypeAliasAssignments (with at least one element) - the type assignment list, followed by in and an arbitrary TypeNode - the subject of the assignments.
• A LocalTypeAliasAssignment is an Identifier followed by = followed by a TypeNode. (does this need to be restricted to parse in a human-understandable way?)

For semantics:

• A LocalTypeAlias is a local scope around its subject type node. It binds a declaration for a type parameter for each identifier in each assignment in its type alias assignment list, constrained to the assigned value, and establishes a TypeMapper to map those type parameters to their assigned value as well (similar to an instantiated generic type alias). (Should they be allowed to be mutually referential? Other parameter lists are, so I don't see why not.) These aliases are made to be type parameters (and not raw aliases like a nongeneric type alias declaration) so they interact favorably with conditional types - eg, they are a way to force a conditional type to iterate over a union for any type node without introducing another top-level alias.

Thoughts?

Start by reviewing the proposed LocalTypeAlias syntax and semantics in the issue, including parsing, scoping, type parameters, and TypeMapper behavior. The payload names no implementation files or tests, so locate the parser and type-checker entry points before proceeding. Done means agreeing on the design and supporting the examples without unresolved questions about mutual references or parsing restrictions.