…ndustries#37047)

Closes zed-industries#36981 

- Add completion text and position caching to reduce redundant API calls
- Only trigger new completion requests on text changes, not cursor
movement
- Validate cursor position to ensure completions show at correct
location
- Improve end-of-line range calculation for more accurate deletions
- Extract reset_completion_cache helper for cleaner code organization
- Update completion diff algorithm documentation for clarity

Edit: Sorry this is the 2nd PR, I forgot that the forks history was
messy; I cherrypicked and cleaned it properly with this PR

Release Notes:

- supermaven: Improved caching of predictions
- supermaven: Fixed an issue where changing cursor position would
incorrectly trigger new completions

Closes #37836

This behavior was already fixed for Supermaven in #37047, but is still
present in Copilot. What's actually happening:
- Receive a multi-line edit prediction
- Dismiss it with escape
- Clicking anywhere in the editor below the cursor calls
`Editor::select` which starts out by calling `Editor::hide_context_menu`
-> `Editor::update_visible_edit_prediction`, bringing back the
prediction that was just dismissed and updating the editor's display map
- The subsequent selection logic in `Editor::select` now operates using
a display map that is inconsistent with what the user saw when clicking
- If the click was anywhere where the prediction inlay used to be,
`Editor::select` thinks the user clicked on the inlay and does nothing,
and the inlay reappears
- If the click was below where the prediction inlay used to be, the
inlay is immediately removed again but the cursor is moved to the wrong
position because the inlay temporarily added a vertical offset to all
lines after it in the buffer

Ultimately, `Editor::select` should be handling the user input using the
same display map that the user saw when making the input. This can
obviously be solved in multiple ways, I chose to clear the current
completions in `CopilotCompletionProvider::discard` such that any
subsequent calls to `Editor::update_visible_edit_prediction` doesn't
immediately nullify the dismissal of the edit prediction by the user.

Note that this also changes the behavior that occurs after dismissing an
edit prediction, moving to a different position in the buffer, and then
returning: currently, this resurfaces the dismissed edit prediction
(which the `test_copilot` test exercises), and after this change it
doesn’t. This current behavior didn't seem desirable to me because it
doesn't happen when using Zeta or Supermaven, but if we want to keep it,
then we could fix the incorrect selection behavior some other way.

Release Notes:

- Fixed bug that resurfaced dismissed Copilot edit predictions when
moving the cursor around

Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Co-authored-by: Ben Brandt <benjamin.j.brandt@gmail.com>