Consider switching `lsp.servers.*.settings` back to `lsp.servers.*.config`

[jolars]

#3254 renamed lsp.servers.*.config to lsp.servers.*.settings, but as me and @MattSturgeon discussed in #3261 it is slightly awkward (and maybe somewhat confusing) because settings is a argument of neovim's LSP config API (:h vim.lsp.ClientConfig), which means that we end up with configs that may look like this

lsp.servers.clangd = {
  enable = true;
  settings.settings = {
    # some settings
  };
};

We could revert and use config again. This brings the API more in line with what the it looks on the neovim side, but #3254 was of course merged for good reasons.

[MattSturgeon]

I'm on the fence here. I'm not opposed to renaming again, given how new/unstable the module is.

I see three simple options:

1. Stick to settings for consistency with other rfc42 style options.
2. Revert to config, matching nvim's vim.lsp.config function name, but causing confusing with the module system's config arg.
3. Find a new name, which may resolve the confusion, but would be inconsistent with both nix convention and nvim's naming.

Alternative

A potential 4th option would be to have two options; one named settings represents what is currently settings.settings (prev config.settings) and another with a different name represents what is currently settings(prevconfig`).

e.g.

lsp.servers.foo = {
  enable = true;

  # maps to `vim.lsp.config('foo', { settings = { /* settings */ } })`
  # could be implemented as `opts.settings = mkIf (settings != {}) settings`
  settings = { };
  
  # maps to `vim.lsp.config('foo', { /* opts */ })`
  opts = { };
}

This idea has some redundancy, but I don't see that as an issue if the module ends being up easier to use.

We wouldn't be able to correctly implement a rename alias for this idea, but I'm happy to compromise here given the module is new/experimental.

[MattSturgeon]

So far, we've been working on the assumption that we should have a freeform option representing ClientConfig.

However, given Neovim document the supported fields, we could instead maintain explicit options for them.

E.g.

lsp.servers.<name> = {
  enable # nixvim option
  package # nixvim option
  cmd # neovim option
  capabilities # neovim option
  setting # neovim option
  luaConfig # nixvim option
}

Usually I'd argue against this increases maintenance burden, but it's easier to justify for such a prevalent feature that's also a built-in part of neovim.