Independent Decoration render support

[IWANABETHATGUY]

The current decoration must be attached to a renderable token,
we use rust-analyzer as a example,

it's inline hint or inline parameter, as you can see, when you move your cursor to the ),
you actually select the :Error ), though the :Error is a decoration.
using this hack method to implement the inline hint like intellij has some drawback

1. When you move your cursor next to a token with an inline hint, your cursor gets very thick including the decorator, which is very inconvenient when you edit your code!
   
   server has a type: TcpListener, if i want to change the variable name , you will see the width of your cursor changes from 12px to 100px.（we assume the width). it's really weird.
2. As a inline hint common implemation method, it's not so pretty.

Feature Request

Is it possible to add an option to have the decoration rendered separately from the original token, whether or not the rendering still relies on certain conditions of the original token.
If this new feature is available, plugin developers can implement the same inline hint as intellij。

[IWANABETHATGUY]

related issue
#16221
#63144
related extension
rust-analyzer
vscode-js-annotations

[IWANABETHATGUY]

here is the intellij inline parameter hint, it's decoration is rendered separate from parameter

[Veetaha]

Related: microsoft/language-server-protocol#956

[ulugbekna]

This would generally be useful for all languages where types can be inferred from C++ to Scala to OCaml.

[Kingwl]

Hey folks.
I'm very interesting and happy to working on this one. It could improve the user experience of inline Hints very much.

There are many ways to do this one as far as I know:

• Core move operation
• Decoration & element layout
• Hack the highlight/selection for decoration
• etc.

But I'm not sure which one is better. Would you give some suggestions ? That would be very helpful to me.
Thanks!

/cc: @jrieken

[alexdima]

@hediet @jrieken I think this issue might be resolved with the new implementation for inlay-hints.

[jrieken]

Yeah, closing as dupe of #16221. We do have a good implementation and API on its way