Encode SymbolKind and SymbolTag as strings

I would like to propose changing the SymbolKind and SymbolTag enum values to strings, so SymbolKind.Function = "function" instead of 3, and so on.

Most languages probably have one or two features that don't quite fit in the existing collection of SymbolKinds (e.g., patterns in Haskell, so this change would allow servers to better handle these edge cases.

On the client side, the spec already says that clients should “handle values outside [the SymbolKind] set gracefully and falls back to a default value when unknown”. Therefore, servers are already allowed to send strings as SymbolKind. I'm simply suggesting to encourage this practice when necessary, and also to make the existing API more consistent with it.

Sending strings as the SymbolKind in edge cases is a reasonable thing to do because, while there isn't anything particularly graceful the client could do with an unknown value of 99, there is definitely something useful it could do with a value of "pattern", or "pragma" (e.g., show that word in a menu).

This is not to say that there shouldn't be an official set of values for SymbolKind, and of course most servers will stick to the official set for better compatibility. Issue https://github.com/microsoft/language-server-protocol/issues/344 remains relevant, as it would be task of the LSP specification to collect the most useful SymbolKinds and make them official.

My interest in this, concretely, concerns the TeX markup languages. In this case, the relevant SymbolKinds would be things like

• chapter/section
• environment
• cross-reference
• citation

and there's nothing reasonable to choose from, even in the way of analogy, from the current options. Now, mine is a very particular case, and I have no hope of convincing you to spec out those things; I myself would be against it if I was in charge of LSP. So I'd rather send the above SymbolKind values as strings to the editor, and let it do its best with that. Surely the editor can create a nice document outline without knowing what the semantics of "chapter" are.

For SymbolTags, it's probably even more desirable to allow nonstandard values to address the idiosyncrasies of particular languages.

Start by locating the SymbolKind and SymbolTag definitions and reviewing the protocol guidance for unknown values and compatibility. Determine whether changing the enum representations to strings is consistent across the specification and client/server expectations; done means the proposal has an agreed design and all affected definitions and guidance are updated.