Turning client-side settings into air.toml files

[lionel-]

With #148 we now support client-side settings. As mentioned by @jennybc, it would be helpful to provide a way to turn such settings into an air.toml file. I'm imagining a custom LSP request that takes a folder path and produces the side effect of creating an air.toml file based on client settings.

• The client sends the request to the server with the path. It should be a folder.
• We send a configuration request from the server to the client with all relevant settings, for that path.
• We get the results and use these to create an air.toml file in the folder.

This can be exposed as a Code command.

And the nice thing is that it would be a convenient way of snapshotting client-side settings in extension tests (cc @juliasilge). We'd set up different scenarios of settings and ask the LSP to create a snapshot of those settings in the form of an air.toml file.

This could also be a way to support editorconfig on the client side (cc @jmcphers). Users of editorconfig files probably have the editorconfig extension enabled, which means the workspace is automatically set up to use the editorconfig settings. So the request described above would be a way to transform an editorconfig file into an air.toml one, at least from VS Code and Positron. Edit: Actually not really because editorconfig changes the settings of editors, not the settings of workspaces, which we would really need here.

[jennybc]

Another situation that sort of inspired those comments is that, at times, I really appreciate git config --list --show-origin for being able to see all the settings that git thinks are currently in force and where they came from, i.e. user config vs. repo config. But, yeah, I also think being able to make air.toml from other possible config sources could be handy.