Named Cycle Type Stringification

[nnullcolumn]

• changes t1 where t1 = ... to Alias where Alias = ...
• fully flagged behind LuauNamedCycleTypes
• authored and ran tests on NixOS 26.05 x86_64 w/ make test
• 100% human made

reading types like t1 can be very unhelpful in types. Currently, exhaustive ToString doesn't really make use of TableType.name/TableType.syntheticName much at all. However, i think we should use both more in places where we otherwise assign junk numbered names. In graph / data-heavy code, you might have a lot of types which are recursive. Here's a sample of a stringified type from my code:

type EntRecord = {
    id: Ent,
    immortal: true?,
    increment: t4?,
    on_adds: t5?,
    on_changes: t6?,
    on_detach: t3?,
    on_removes: t2?,
    stable_frag: t1,
    stable_row: FragRow,
    var_frag: t1,
    var_row: FragRow,
} where t1 = {
	read adjacent: { [Id]: t1? },
	clean_count: FragRow | Zero,
	...

Although I could use an in-exhaustive ToString and enable synthetic names, that'd make the entire type display as EntRecord, hiding a bunch of useful information. Instead, after putting a version of my code into an exhaustive ToString with my changes, I got something like this:

type EntRecord = {
	id: Ent,
	immortal: true?,
	increment: Increment?,
	on_adds: SignalAdds?,
	on_changes: SignalChanges?,
	on_detach: SignalDetach?,
	on_removes: SignalRemoves?,
	stable_frag: Frag,
	stable_row: FragRow,
	var_frag: Frag,
	var_row: FragRow
} where Frag = {
	read adjacent: { [Id]: Frag? },
	clean_count: FragRow | Zero,
	...

this is still exhaustive (which is super useful!), but objectively better to read.

if ignoreSyntheticName is enabled in ToStringOpts, tests make sure it still shows t1 where t1 = ... for recursive types without a type namespace name.

[nnullcolumn]

looks like i have some test cases to work on