We need to change the way we represent type aliases to be more like classes, to handle recursive aliases. Right the aliased type is stored inline, making recursion impossible; all recursive references are treated as Unknown.

This can be solved with a layer of indirection - we could have TypeAlias store a unique identifier, and look up the aliased type somewhere else. This would be similar to how we have a ClassType and use it to look up the ClassMetadata. Because of this indirection, we would need to store type arguments for any instantiated type aliases so that we can use it to instantiate the forall after looking up the type - the overall structure is very similar to Class v.s. ClassType.

This indirection would solve the problem for type aliases created with TypeAlias or the type statement.

There are two tricky parts here, related to how we extend the solution to implicit type aliases. Right now, we decide whether something is an implicit type alias at the solver phase, if the RHS expression is a particular type.

This means that we're missing information that we need in the bindings step:

1. whether or not to generate the new type alias bindings
2. whether or not we should process a string as a type or a string literal (we only call parse_type_literal on the ensure_type code path, so it only gets used in places where we're sure we're dealing with a type annotation - this means that stringified types don't work at all for implicit type aliases ATM, but they need to)

We could solve it by always generating the bindings, and having it resolve to either a type alias or some NotATypeAlias, and raise an error when we try to use the latter as a type alias. This feels pretty clunky though, and would be akin to having a bunch of Classes floating around where we need to verify that it's actually a class before we try to use it.