Make ScriptElementKind and HighlightSpanKind string enums

[ghost]

Note: is technically a change to our public API as many strings are now ScriptElementKinds. And anyone using the API must now have ts@next or they will get compile errors on the string enums -- but presumably people compiling against the ts@next API are compiling using ts@next too.
Required running gulp LKG to get #15486 in.

[mhegazy]

should also change ScriptElementKindModifier to be an enum.

[mhegazy]

and ClassificationTypeNames

[mhegazy]

also server.CommandTypes

[mhegazy]

and HighlightSpanKind

[mhegazy]

and ClassificationTypeNames

[mhegazy]

also server.CommandTypes

[mhegazy]

and HighlightSpanKind

[mhegazy]

Also please add a note for this in https://github.com/Microsoft/TypeScript/wiki/API-Breaking-Changes#typescript-24

[ghost]

@mhegazy Is there any reason to avoid a non-const enum in protocol.ts? We iterate over for (const name in CommandNames) in a unit test (and now CommandNames = CommandTypes).

[mhegazy]

this should be const enum, since it does not exist at time of building the client against the protocol file.

[ghost]

We need to iterate over it though -- I guess I could define a CommandTypes[] elsewhere but we'd have to remember to update both places every time a new command is added.

[mhegazy]

missing the initialization here.

[mhegazy]

@mhegazy Is there any reason to avoid a non-const enum in protocol.ts? We iterate over for (const name in CommandNames) in a unit test (and now CommandNames = CommandTypes).

yes. protocol.ts compiles down to protocol.d.ts which is then used by the clients to compile against.

so either we make them const in protocol.ts or do that while we put together protocol.d.ts in buildProtocol.js.