Add provideCompletionItem middleware to rewrite MP snippet filterText

[sharma1208]

Problem

MicroProfile snippet completion items (mpliveness, mpreadiness, mpnrc) only surface in VS Code when the user types the exact prefix mp. Typing a meaningful word fragment like live, health, or readi returns nothing.

The MP language server sets both label and filterText to the same short lowercase token (e.g. "mpliveness"). VS Code's fuzzyScore requires matched characters to start at a word boundary like an uppercase letter, space, or start of string. A string like "mpliveness" has no boundaries, so only a prefix matches.

This works fine in IntelliJ (LSP4IJ registers both filterText and label as lookup strings) and Eclipse (LSP4E uses ordered subsequence matching), but VS Code has no equivalent layer.

Fix

Add a provideCompletionItem middleware hook that rewrites filterText from the opaque token to item.detail (e.g. "mpliveness" → "MicroProfile Health liveness check") before items are returned to VS Code. This gives the fuzzy engine real word boundaries to match against.

The rewrite is guarded so it only applies when filterText and detail exist and differ, so regular Java completions are unaffected.

What works after this fix

Query	Result
mp	works (unchanged)
live	now works
readi	now works
health	now works
check	now works

Known limitation

Pure mid-word subsequences like ven (no word boundary before v in liveness) are not achievable with VS Code's boundary-anchored fuzzyScore regardless of the filterText value. This is a fundamental engine difference from LSP4E's subsequence matching.

Testing

Tested locally via Extension Development Host against a MicroProfile Gradle project.
Confirmed via provideCompletionItem middleware logging that item.detail carries the human-readable string and that rewriting filterText to it produces correct fuzzy matches.

Fixes OpenLiberty/liberty-tools-vscode#341
and Fixes #609