[clang-tools-extra] [clangd] Add languages as server capabilities (PR #75633)

[Chris B via cfe-commits]

llvm-beanz wrote:

> 1. Since the key we're adding to the server capabilities is a non-standard extension, I'm a bit uneasy about giving it a general name like `"languages"`. If the LSP were to add a key with that name but a different format or interpretation, we could run into trouble. Can we name it `"clangdLanguages"` instead, thereby staying within our own (improvised) "namespace"?

+1 This makes sense.

> 2. Given that the plan described by Sam in [this comment](https://github.com/clangd/vscode-clangd/pull/392#issuecomment-1285902875) is to enable vscode-clangd support for HLSL by default once clang's support for HLSL is a good enough state, what do you think about the following arrangement:
>    * don't include `"hlsl"` in `"clangdLanguages"` yet
>    * add `"hlsl"` to `"clangdLanguages"` once the "good enough" threshold is reached
>    * on the client side, add HLSL to the document selector if the server announces support for `"hlsl"` in `"clangdLanguages"`, **or** a client-side preference (which we could name "experimental", e.g. `"clangd.experimentalHLSLSupport"`) is enabled?

What about a slightly different take? What if in addition to adding `clangdLanguages` (without HLSL) we also add `clangdExperimentalFeatures` and add `HLSL` there. The problem I'm trying to solve here is to avoid someone enabling HLSL on a language server that doesn't advertise that it has support.

That would still allow your points:
    
>    * early adopters can set `"clangd.experimentalHLSLSupport"` with an up-to-date client paired even with a clangd 17 or older server, and get the corresponding level of support
>    * once the implementation quality is good enough, the server can start announcing the support and all clients (not just early adopters who set the pref) will have it by default with newer server versions



https://github.com/llvm/llvm-project/pull/75633