dillon1000/react

[RFC] Stabilize naming of promoted temporaries

When the compiler promotes temporary values to named variables, we currently 
eagerly assign a name using the temporary's IdentifierId. This means that we're 
sort of stuck with this name later in compilation, and RenameVariables can't be 
100% sure whether a 't0' variable is a temporary or not. As a result, the names 
of these promoted temporaries is influenced by how many temporaries we happened 
to create during compilation (and what the next available identifier id was), 
making them fluctuate more as we iterate on the compiler. 

This is an RFC for showing how we can stabilize these names. The key elements: 

* Distinguish promoted temporaries from other named identifiers. Here we use a 
hack, naming them starting with '#t' or '#T', since '#' isn't a valid identifier 
starting point. This lets us keep all of our logic that looks for non-null 
identifiers names to distinguish named/unnamed, while also distinguishing real 
names from generated names (if this was Rust, we'd use an Enum and have a 
"isNamed()" method on it that was true for real/temporary names and false 
otherwise) 

* In RenameVariables, detect generated names and fall back to generating the 
next available `tN`-style name (or `TN` for JSX tags). 

* To reduce thrash overall, RenameVariables no longer keeps a global "next id" 
value that uses to distinguish all conflicting identifiers, instead we restart 
at 0 whenever we find a conflict, and keep bumping until we find a free name. 
Thus if both `foo` and `bar` had conflicts, we previously would end up with 
`foo$0` and `bar$1` as the deduped names, but now will end up with `foo$0` and 
`bar$0`. 

## RFC 

I'm open to feedback on the approach. Two main questions: 

* How to annotate promoted temporaries. The most type-safe option is to change 
`Identifier.name` to be a union of `{kind: 'named', value: string} | `{kind: 
'promoted', value: string} | `{kind: 'temporary'}` though TS then wouldn't allow 
`identifier.name.value` (even as nullable) since it doesn't exist on one of the 
variants. Maybe we could type the temporary one as `{kind: 'temporary', value?: 
null}` so the value has to be null but you can always access that property? 

* ?? Other concerns about the approach? We could keep the global 
auto-incrementing id rather than attempting to reset to 0 for each conflict.