feat: add full semantic token support

[NJichev]

Opening this to start a discussion on what should be a part of this PR.
Currently all this does is add support for semanticTokens/full and parameters on def/defp/defmacro/defmacrop.
On my wishlist is to add support for the range and delta requests as well(which are on right now by the provider).
For the delta requests I might store the old result of the previous request on the lsp assigns which should be okay.

I need some ideas on what else we could add other than parameters. I'll take a look at other implementations and what they add. The protocol defines a list of default types and modifiers but bear in mind that we can add our own custom ones to the legend sent at the initialization part.

[mhanberg]

Can you post some before and afters of your editor showcasing the feature?

[NJichev]

How the highlighting works without the feature:

Here's how it looks like with the semantic token support:

We can see in the second screenshot that the "document" parameter is highlighted differently(the :Inspect from neovim is on "document" parameter). Next-ls has sent additional information to the editor for this token @lsp.type.parameter.elixir which clients can override and display in their own way. (ignore the coloring since it's the default from my theme and looks the same as atoms).
The goal of this PR should be to identify other "special" types of tokens that would be useful for developers to customize before adding it as a feature.

I'll leave two articles on the semantic highlighting from VSCode:
https://code.visualstudio.com/api/language-extensions/semantic-highlight-guide#:~:text=Semantic%20tokenization%20allows%20language%20servers,the%20syntax%20highlighting%20from%20grammars

And jetbrains:
https://blog.jetbrains.com/pycharm/2017/01/make-sense-of-your-variables-at-a-glance-with-semantic-highlighting/

[NJichev]

A nice usage could be adding a different type to macros such as @lsp.type.macro.elixir. Let's say for an example we have:
Logger.warn "a warning", this type would be added to the warn token allowing the user to customize how the colorscheme works.

Note that we would want to be careful here since all operators could easily be interpreted as macros as well breaking all colorschemes in the process. We would probably want to exclude any Kernel level macros from this.