Add commands to open global and project config

[njames93]

Global config opening will likely not work on remote setups and is as of yet untested on windows and mac builds.

Fixes #176

[sam-mccall]

Thanks for putting this together!
I'm not 100% sure that we have enough info to decide where the project config should go, but maybe my vscode usage is atypical. @hokein @kbobyrev WDYT about writing .clangd to workspace folders?

[sam-mccall]

Hmm, how sure are we that this is the right directory (that workspace folders correspond to the real project root, and folder 0 is the right one?)

[njames93]

There's unfortunately not a great way of going about this. In a single workspace mode this should be sufficient. But once you start working with multi folder workspaces things start getting a little hazy. However a lot of projects users are likely to work on only have 1 root folder so this should be helpful for the majority of users.

[hokein]

Thanks for putting this together!
I'm not 100% sure that we have enough info to decide where the project config should go, but maybe my vscode usage is atypical. @hokein @kbobyrev WDYT about writing .clangd to workspace folders?

I think that depends on everyone's workflow. Just speaking for myself, the current model (assuming the workspacefolders[0] as the project root) at lease works for me, because I use llvm-project directory in vscode during the llvm development.

I think this is a useful feature, but the current model seems fragile to me:

• for a monolithic codebase, people working on a subproject likely use the subdirectory (e.g. clang_tools_extra/clangd) as the workspace folder in vscode. For this case, the command will create .clangd in the llvm-project/clang_tools_extra/clangd directory, but we expect that the project config should be in llvm-project/.
• should we respect the currently-editing file in vscode (I think yes)? Think about a case where we have llvm-project workspace folder in vscode, then we open and edit an out-of-workspace-folder file /tmp/t.cpp, now we invoke a open project config command, should we open the .clangd in llvm-project, or there is no project config (respecting the currently-editing /tmp/t.cpp), or create a .clangd in /tmp/?
• another observation is that we are mirroring the config behavior in vscode client, this might lead to subtle diverging bugs in the future.

I was going to suggest that we can add some extensions like getConfigInfo in clangd server, then the client can query clangd to get the config information, but realized that clangd doesn't know the concept of project directory :(

[sam-mccall]

LGTM with one nit around initialization that I can fix myself.

---

Project config:

This isn't going to free people from having to know where .clangd files go, but it's going to put them in a predictable place that will work a good fraction of the time. I think it's a fair tradeoff.

I was going to suggest that we can add some extensions like getConfigInfo in clangd server, then the client can query clangd to get the config information, but realized that clangd doesn't know the concept of project directory :(

This is obviously pretty heavyweight. I can imagine some refinements to make it work better, but I don't think it's worth it.

---

It'd be nice to expose these from the status bar item, but that doesn't look possible as we have a primary action already (open log) and microsoft/vscode#27196 isn't done.

[sam-mccall]

nit: OpenConfig -> openConfig

For whatever reason, our idiom is to features from clangd-context.ts, passing in ClangdContext instead of ExtensionContext.
(I think it might be something to do with allowing the server to be restarted, we unload and reload all features. It's not actually important for this feature but best to be consistent)

[njames93]

The reason I passed the ExtensionContext is because the commands don't actually depend on the clangd server being active. However there's very little real world difference in using ClangdContext and consistency is a good thing.