If vim.lsp.log is loaded the second time,
the vim.log.levels will be modified with additional
entries from 0-5.
This will cause the require to fail as level:lower does
not exists on numbered value.
Adds function to notify the user like this:
`:lua vim.notify("hello user")`
embeds log levels vim.log.levels.
you can then reassign vim.notify to for instance
```
function notify_external(msg, log_level, opts)
vim.fn.jobstart({"notify-send", msg })
end
```
while there is some controversy, stdpath('cache') looks like a better fit for logs than stdpath('data'): you can remove logs without preventing nvim to work which fits the XDG_CACHE_HOME definition of `user specific non-essential data files`.
It's confusing because vim-lsp already has the same name as the plugin name that predates this built-in lsp.
Also, since "vim.fn.stdpath" is used, adding the prefix "nvim-" is redundant, so just "lsp.log" will suffice.
According to the LSP specification, showMessage is what is displayed and logMessage is what is stored.
Since these are different things, I devide the callback into those that match.
Mainly configuration and RPC infrastructure can be considered "done". Specific requests and their callbacks will be improved later (and also served by plugins). There are also some TODO:s for the client itself, like incremental updates.
Co-authored by at-tjdevries and at-h-michael, with many review/suggestion contributions.
