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