* preserve fields from LSP diagnostics via adding a user_data table to the diagnostic, which can hold arbitrary data in addition to the lsp diagnostic information.

These links were actually defined backwards: the highlight groups
actually being used for display are the new "Diagnostic*" groups, so
linking the old "LspDiagnostics*" groups to these does absolutely
nothing, since there is nothing actually being highlighted with the
LspDiagnostics* groups.

These links were made in an attempt to preserve backward compatibility
with existing colorschemes. We could reverse the links to maintain this
preservation, but then that disallows us from actually defining default
values for the new highlight groups.

Instead, just remove the links and be done with the old LspDiagnostics*
highlight groups.

This is not technically a breaking change: the breaking change already
happened in #15585, but this PR just makes that explicit.

This generalizes diagnostic handling outside of just the scope of LSP.
LSP clients are now a specific case of a diagnostic producer, but the
diagnostic subsystem is decoupled from the LSP subsystem (or will be,
eventually).

More discussion at [1].

[1]: https://github.com/neovim/neovim/pull/15585

Fixes #15522

Previously, the handler signature was:

  function(err, method, params, client_id, bufnr, config)

In order to better support external plugins that wish to extend the
protocol, there is other information which would be advantageous to
forward to the client, such as the original params of the request that
generated the callback.

In order to do this, we would need to break symmetry of the handlers, to
add an additional "params" as the 7th argument.

Instead, this PR changes the signature of the handlers to:

  function(err, result, ctx, config)

where ctx (the context) includes params, client_id, and bufnr. This also leaves
flexibility for future use-cases.

BREAKING_CHANGE: changes the signature of the built-in client handlers, requiring
updating handler calls

Add two new methods to allow diagnostics to be disabled (and re-enabled)
in the current buffer. When diagnostics are disabled they are simply not
displayed to the user, but they are still sent by the server and
processed by the client.

Disabling diagnostics can be helpful in a number of scenarios. For
example, if one is working on a buffer with an overwhelming amount of
diagnostic warnings it can be helpful to simply disable diagnostics
without disabling the LSP client entirely. This also allows users more
flexibility on when and how they may want diagnostic information to be
displayed. For example, some users may not want to display diagnostic
information until after the buffer is first written.

Makes it easier to re-use the logic to populate the quickfix list
instead of the location list.