FindReplaceOverlay: Add "skip replace" button

[Wittmaxi]

support the workflow in which a user selectively wants to replace multiple occurrences but needs to check first which to replace. Adds a button associated to a shortcut which - when triggered - simply jumps to the next occurrence of the search term.

This PR is a test to see whether this is something that adds user value. Adding this button is slightly awkward since it does exactly the same thing as "find next" - except that it can be reached by shortcut (Ctrl+Shift+O) from the Replace bar.

If this PR is approved (help wanted!), these are the next steps:

• agree on an icon
• publish the icon on the images repo
• write a unit test

[Wittmaxi]

Screencast.from.2024-11-08.15-06-50.webm

I don't like the icon yet. Any suggestions?

[Wittmaxi]

@stephan-herrmann you proposed this in #2473.
Is this something that addresses your concern?

[github-actions]

Test Results

   907 files   -   607     907 suites   - 607   31m 44s ⏱️ - 1h 3m 15s
 7 725 tests ±    0   7 496 ✅ +    1  229 💤 ±  0  0 ❌  - 1 
14 378 runs   - 8 112  14 110 ✅  - 7 831  268 💤  - 280  0 ❌  - 1 

Results for commit 8a48723. ± Comparison against base commit 10d96b5.

[HeikoKlare]

I have to admit that I am not in favor of the proposed change. This is because the solution does not address the essence of the actual issue. The solution adds another button (to a user interface that is/was supposed to be lean), while there is already a button doing exactly the same thing. If I understand correctly, it is just there to provide an additional keyboard shortcut.

Would it, e.g., be better to adapt the shortcuts assigned to the existing buttons depending on which of the input fields has foucs? I am not completely convinced that that's a perfect solution (as I see changing shortcuts as conflicting to good UX in terms of expectability), but since the meaning of shortcuts is context dependent already now ("Enter" does different things depending on whether the find or replace input field has focus), that might be a reasonable alternative.
So concretely: the find/replace buttons have the current shortcuts assigned whenever the according input field has focus (which is exactly the behavior we have right now). When the other input field has focus, the shortcuts are changed, e.g., by adding some modifier, such that MODIFIED+Enter executes a search when the replace input field has focus, or executes a replace when the find input field has focus.

Note that the shortcut currently assigned to the new button has no effect on Windows (at least in my development SDK).

[stephan-herrmann]

@stephan-herrmann you proposed this in #2473. Is this something that addresses your concern?

Sorry for late reply. Rethinking, I agree with @HeikoKlare that not a new button is needed, but some change to keybindings.

@HeikoKlare you mentioned Ctrl+K for find next, since which version is this implemented? (doesn't work for me in 2024-09, as long as the overlay is shown). Actually without consulting any "manual" I would expect one of these: F3 (like in several other applications, but already used for "Find Declaration") or repeated Ctrl+F (already used for hiding the overlay, but that's redundant with Esc, right?).