refactor(lsp): resolve the config-client entanglement

Previously the LSP-Client object contained some fields that are also
in the client config, but for a lot of other fields, the config was used
directly making the two objects vaguely entangled with either not having
a clear role.

Now the config object is treated purely as config (read-only) from the
client, and any fields the client needs from the config are now copied
in as additional fields.

This means:
- the config object is no longet normalised and is left as the user
  provided it.
- the client only reads the config on creation of the client and all
  other implementations now read the clients version of the fields.

In addition, internal support for multiple callbacks has been added to
the client so the client tracking logic (done in lua.lsp) can be done
more robustly instead of wrapping the user callbacks which may error.

runtime/lua/vim/lsp/_watchfiles.lua

@@ -44,12 +44,8 @@ function M.register(reg, ctx)
   local client = assert(vim.lsp.get_client_by_id(client_id), 'Client must be running')
   -- Ill-behaved servers may not honor the client capability and try to register
   -- anyway, so ignore requests when the user has opted out of the feature.
-  local has_capability = vim.tbl_get(
-    client.config.capabilities or {},
-    'workspace',
-    'didChangeWatchedFiles',
-    'dynamicRegistration'
-  )
+  local has_capability =
+    vim.tbl_get(client.capabilities, 'workspace', 'didChangeWatchedFiles', 'dynamicRegistration')
   if not has_capability or not client.workspace_folders then
     return
   end