Extending lspconfig's default configs should be reflected in mason-lspconfig's mapping

[bnwa]

Is your feature request related to a problem? Please describe.

I'm testing adding a LSP package for Fish shell to Mason in a local registry. I can properly register the local registry, install the LSP package, and evoke the LSP directly via vim.lsp.start. The trouble comes when trying to evoke the installed LSP through the layers of nvim-lspconfig in concert with mason-lspconfig.

Since nvim-lspconfig.configs does not feature this LSP server, one must extend that object so that the _newindex metamethod therein picks it up. However, mason-lspconfig.mapping.servers is a static list. So attempting to add a handler for this new LSP to mason-lspconfig results in a predictable mason-lspconfig.setup_handlers: Received handler for unknown lspconfig server name: fish-language-server.

Describe the solution you'd like

I understand the workaround is to iterate the the installed server names that have a mapping in mason-lspconfig.mapping.servers however I think it may be an improvement to dynamically generate the server mapping from the maintained static mapping, so that servers added to nvim-lspconfig.configs via extension are passthrough registered with their given key and identical value. So in this case, I would expect to populate mapping.servers with, e.g. ['fish-language-server'] = 'fish-language'server'.

Describe potential alternatives you've considered

No response

Additional context

No response