fixes glob spec regression related to "zero or more" vs "one or more" for `*`
ref: https://github.com/microsoft/language-server-protocol/issues/2217

From the LSP Spec:
> There are two uses cases where it can be beneficial to only compute
> semantic tokens for a visible range:
>
> - for faster rendering of the tokens in the user interface when a user
>   opens a file. In this use case, servers should also implement the
>   textDocument/semanticTokens/full request as well to allow for flicker
>   free scrolling and semantic coloring of a minimap.
> - if computing semantic tokens for a full document is too expensive,
>   servers can only provide a range call. In this case, the client might
>   not render a minimap correctly or might even decide to not show any
>   semantic tokens at all.

This commit unifies the usage of range and full/delta requests as
recommended by the LSP spec and aligns neovim with the way other LSP
clients use these request types for semantic tokens.

When a server supports range requests, neovim will simultaneously send a
range request and a full/delta request when first opening a file, and
will continue to issue range requests until a full response is
processed. At that point, range requests cease and full (or delta)
requests are used going forward. The range request should allow servers
to return a result faster for quicker highlighting of the file while it
works on the potentially more expensive full result. If a server decides
the full result is too expensive, it can just error out that request,
and neovim will continue to use range requests.

This commit also fixes and cleans up some other things:

- gen_lsp: registrationMethod or registrationOptions imply dynamic
  registration support
- move autocmd creation/deletion to on_attach/on_detach
- debounce requests due to server refresh notifications
- fix off by one issue in tokens_to_ranges() iteration

Problem:
Previously, 'null' value in LSP responses were decoded as 'nil'.
This caused ambiguity for fields typed as '? | null' and led to
loss of explicit 'null' values, particularly in 'data' parameters.

Solution:
Decode all JSON 'null' values as 'vim.NIL' and adjust handling
where needed. This better aligns with the LSP specification,
where 'null' and absent fields are distinct, and 'null' should
not be used to represent missing values.

This also enables proper validation of response messages to
ensure that exactly one of 'result' or 'error' is present, as
required by the JSON-RPC specification.

- Simplify usage:
  - Instead of `nvim -l src/gen/gen_lsp.lua gen` now just
    run `./src/gen/gen_lsp.lua`

- Removed `--methods` and `--capabilities` options.

- Improved rendering code in various areas.

This change modifies gen_lsp.lua so alias types are generated for
various types of lsp methods to distinguish between notifications
and requests:
 - vim.lsp.protocol.Method.ServerToClient.Request
 - vim.lsp.protocol.Method.ServerToClient.Notification
 - vim.lsp.protocol.Method.ClientToServer.Request
 - vim.lsp.protocol.Method.ClientToServer.Notification

 These types are then used instead of `string` where appropriate.

Added the enum type annotation `vim.lsp.protocol.Methods` to provide some intellisense support.

Make the LSP protocol typings up-to-date with LSP protocol (upcoming)
version 3.18, before and in preparation for the Nvim 0.10.0 release.