feat: allow providers customize documentation rendering

[mikavilpas]

This is another attempt at #462

Issue

The default way of rendering documentation using markdown and treesitter
works great for most cases, but some providers may want to customize the
rendering of the documentation.

However, some providers may want to customize the rendering in order to
add additional information or custom highlighting.

Solution

Add a new field render_documentation_fn to the CompletionItem type.
Providers can set this to a function that will be called when the
documentation is about to be rendered. They can then choose to do custom
rendering or fallback to the default rendering.

Use cases:

• when a treesitter parser is not available for code examples, providers
  can display colored text using Neovim's regex based syntax highlighting
• can add additional highlighting to the documentation
• avoid showing extra empty lines caused by markdown fenced code blocks

mini demo:

doc-demo.mov

[mikavilpas]

There are also other approaches available:

• instead of having the render documentation function be a part of completion results, it could be a part of the provider. Then the documentation could be rendered by resolving the provider and calling it. This might offer some performance benefits because it probably avoids creating tons of closures when there are many completions (not sure if this is useful tbh)
• a more granular method of customizing the default rendering could be used, but that requires a bit more refactoring and design
• right now the default rendering is passed as a function to the custom rendering. This allows the provider to make a choice about whether they want to fall back to it, or run it and then possibly add some customization on top. This might not work that well in all cases because so much of the internals are exposed. A better way could be to only allow the choice of completely overriding it, or falling back to the default (a bit like in the middleware/monad pattern)

[Saghen]

This looks great, thank you! Sorry I didn't get to this earlier. I've moved the render_documentation_fn to documentation.render and changed both render functions (default and custom) to use a table for the options so it's easy to add more properties later without disruptive breaking changes

This might offer some performance benefits because it probably avoids creating tons of closures when there are many completions (not sure if this is useful tbh)

I'd recommended filling in the documentation.render only on resolve since it shouldn't be needed otherwise

This might not work that well in all cases because so much of the internals are exposed. A better way could be to only allow the choice of completely overriding it, or falling back to the default (a bit like in the middleware/monad pattern)

Yeah, especially since changes to that render function could be considered breaking changes. When writing the documentation, I'll be sure to mention it can change at any time and keep it as is for now

[mikavilpas]

Awesome! No worries, blink has basically exploded in the past week 😄