Emit non-identifier enum member references as typeof parent[some name]

[weswigham]

Fixes #40152

What we generate to refer to a non-identifier named enum on master, E.1-2, is syntactically invalid emit. E["1-2"] would refer to the "1-2" member of the type E (which is the union of all enum members), so doesn't exist (and wouldn't refer to what we wanted if it did). So the best we could do is typeof E["1-2"] - which looks up the value type of E and pulls out the type of the "1-2" property form it, which, in the case of enums, is fortunately the same as the type provided by the E.1-2 namespace member, so is what we're looking for.

This solves the immediate issue brought up by #40152 with a special case in the node builder to build out the access described above, however, generally speaking, the type side of non-identifier-named namespace members are not currently accessible via any syntax means. This is in some ways an oversight - until we gave enum members distinct type identities for literal-typed enums, we had no syntax allowing one to declare a namespace member with a non-identifier name. That, plus JS binding (which allows arbitrary non-identifier names via element access assignment bindings), however, allow such things to be constructed - and as such, we now need to consider a suite of syntax updates we can use to appropriately serialize and represent them in declaration emit. I should have another proposal to at least partially remedy that root issue (in the style of allowing NS."quoted member name"."another one" accesses) in the nearish future.

[sheetalkamat]

Another test for const enum ?

[weswigham]

'const' enums can only be used in property or index access expressions or the right hand side of an import declaration or export assignment or type query. - it can't be spread.