feat: implement ghost text and generalize inline elements

[itsvks19]

Refactors the InlayHint system into a generic InlineElement architecture to support inline code completion.

• Introduce InlineElement interface, InlineElementContainer, and InlineElementRenderer
• Implement GhostText and GhostTextRenderer for displaying completion suggestions
• Add InlineCompletionProvider API and requireInlineCompletion in Language
• Update CodeEditor to support setInlineCompletionProvider and handle Tab key to accept ghost text
• Refactor TextRow, LineBreakLayout, and WordwrapLayout to use InlineElement instead of InlayHint
• Add GHOST_TEXT_FOREGROUND to EditorColorScheme

Screencast.From.2025-12-02.23-26-42.mp4

Limitations

• currently it only supports single line completions

[dingyi222666]

I have a few questions:

1. Does the rendered text support multi-line display and word wrapping? (As shown in the image below)

2. Is the getInstance method in GhostTextRenderer necessary? Is there any risk of memory leaks?

3. Does InlineCompletionItem support multi-line content (i.e., setting different display lines and defining the cursor position after the completion is applied)?

[itsvks19]

Does the rendered text support multi-line display and word wrapping? (As shown in the image below)

No, currently it only supports single line completions. It can be extended to support multiline completions.

Is the getInstance method in GhostTextRenderer necessary? Is there any risk of memory leaks?

It is not necessary now, but when I created that function I was added all editor's event listeners in that function but later I used GhostTextRenderer's init { } block for registering event listeners. Sorry, I forgot to remove that function.

Does InlineCompletionItem support multi-line content (i.e., setting different display lines and defining the cursor position after the completion is applied)?

It is absolutely possible but I need to make some changes, currently editor only renders one GhostText even if there are many GhostTexts present.

[Rosemoe]

Here are my thoughts about the changes to inlay hints and inline elements:

• use layout instead of renderer for inline elements, and inline element layout is capable of:
  • break associated logic elements into row fragments, and fits editor viewport in wordwrap mode
  • measure and draw the row fragments generated
• add LineLayout to layout a single line with logic inline elements to rows with their row fragments
• inlay hint works with a subset of inline element funcitonalities (inlay hints can not be multi-line or fit wordwrap)
• editor layout takes care of line layouts
  • LineBreakLayout creates specific line layout if required (multi-line element detected)
  • WordwrapLayout always layout all lines
• TextRow can draw according to a list of visually-reordered row fragments
• TextRow can locate what row fragment is clicked by horizontal offset

[itsvks19]

I will keep the InlineElementRenderer interface as it is.
It will help user to add their own InlineElement such as Git Blame Annotation.