Decline a stale inlay hint request instead of answering it with nothing

[SuperFes]

I recently found your project and was interested in its features in lieu of a few other LSPs, the list of features was impressive, and e.g. you can trust Rust not to go crazy.

In using the LSP I have run into a specific issue, wherein when a buffer is modified the flow control of type-hints gets pretty weird.

This small patch has fixed my issue, and may be beneficial to your project, feel free to review the changes and comments.

I ran the stuff listed in your contribution guidelines and it ends with: [ERROR] Found 1434 errors... I assume this is expected?

Anyways, excited to see your project grow!

--

The symbol map a file's hints are read from is rebuilt on a background task, so a request arriving between a keystroke and that rebuild was answered with offsets describing the previous text: labels landed inside the arguments they name, and because the visible range was measured against the newer text while the hints were not, the following call's hints were pulled onto the edited line and drawn twice.

handle_inlay_hints now declines that request. Returning Ok(None) for it is not enough on its own -- a null result is indistinguishable from "no hints here", so a client replaces the labels it is showing with an empty set and the line stays bare until something re-pulls it. Answering ContentModified says what actually happened, and a client that understands it keeps what it has and re-pulls on the inlayHint/refresh sent once the rebuild commits.

No content to work from, or a blocking task that died, still answer Ok(None): neither is a document-version problem, and re-requesting would not change either one.

Checklist

If applicable:

• I have updated CHANGELOG.md
• I have updated the documentation (README.md, docs/, examples/)
• I have updated the config schema (config-schema.json)
• I have added/updated tests to cover my changes
• I fully understand the code that I am submitting (what it does,
  how it works, how it's organized), including any code drafted by an LLM.
• For any prose generated by an LLM, I have proof-read and copy-edited with
  an eye towards deleting anything that is irrelevant, clarifying anything
  that is confusing, and adding details that are relevant. This includes,
  for example, commit descriptions, PR descriptions, and code comments.