feature request: expose configurations for direct use

[kylo252]

Description

It's currently not easy to retrieve the default configuration

print(vim.inspect(require("lspconfig.zls")) -- this probably won't give you anything useful

You actually need to interact with the configs singleton,

print(vim.inspect(require("lspconfig.configs.zls")) -- common gotcha, but won't print anything useful either
print(vim.inspect(require("lspconfig/configs")["zls"]) -- this is the one you want

The problem is that this will result in LspInfo thinking that you've configured that zls server, even though you have only been interested in seeing the defaults #1302.

But why is this happening? Remember how I said I that configs is a singleton? Let's test that. Assume you have a setup function similar to https://github.com/mjlbach/defaults.nvim/blob/cddcfb7821f4799df8767f362fc3d024be4fd7d1/init.lua#L233, so something like this:

local servers = { "clangd", "sumneko_lua", "bashls", "dockerls", "jsonls", "yamlls", "pyright", "cmake" }

for _, server in ipairs(servers) do
  require("lspconfig")[server].setup()
end

What do you think should the result be at startup when you haven't even opened a single file yet? Well, you can just see for yourself.

print(vim.inspect("lspconfig/configs"))

Motivation

We can do better

There are people who are a lot smarter than me that can explain why singletons can be an anti-pattern, so I won't dive into that. Instead, I'll just say that there's no technical reason to keep using this design. Maybe it's more practical, but it's generally not needed. Please correct me if I'm wrong.

Re-usability

You may want to read some configuration to offer an API for X functionality in your plugin, williamboman/nvim-lsp-installer#117 (comment). Or you want to setup something fancier, williamboman/nvim-lsp-installer#184 (comment).

Suggested solution

This will probably require a big refactor, but some obvious steps could be:

1. break out the manager component from configs.
2. make sure that the manager module is actually independent and does not rely on any global variables/states.
3. convert each server into their own independent modules. each having something akin to
   myserver.get_default_config() and clangd.setup(). You're free to decide on the implementation details of myserver.setup(), in case you prefer to minimize or eliminate breaking the current API.
4. allow LspInfo to operate independently, by completely ignoring the configs module and only relying on vim.lsp.get_active_clients() and myserver.get_default_config().

[mjlbach]

This is already documented/milestoned in the lspconfig roadmap #1221