[FindNextAction] synchronize search history with FindReplaceOverlay

[Wittmaxi]

synchronize search history with the FindReplaceOverlay and FindReplaceDialog.

This fix is not as extensive as a prior attempt (#2308) and thus does not require as much testing. Since this is a high-priority issue, we want this to be fixed ASAP.

1. search histories and options are now stored at a centralized place - in the options for the FindReplaceAction class.
2. the name of the search history settings section is now unified
3. the search history component of the Find/Replace Overlay now updates it's history on the fly to accomodate.

[github-actions]

Test Results

 1 821 files  ±0   1 821 suites  ±0   2h 5m 25s ⏱️ + 13m 42s
 7 714 tests ±0   7 486 ✅ ±0  228 💤 ±0  0 ❌ ±0 
24 303 runs  ±0  23 556 ✅ ±0  747 💤 ±0  0 ❌ ±0 

Results for commit 0cd7720. ± Comparison against base commit 5c9af91.

♻️ This comment has been updated with latest results.

[HeikoKlare]

Sharing the settings between the dialog and the overlay is good. The current proposal will produce a regression in the dialog, which needs to be resolved.

[HeikoKlare]

This will break the FindReplaceDialog, as it still uses the subsection according to its class name. Shouldn't we use a subsection in the dialog settings of the bundle, e.g., using the class name of the FindReplaceAction class, like done with the FindReplaceDialog before?

[Wittmaxi]

I have made it so that FindReplaceDialog, FindReplaceOverlay and FindNextAction have the exact same method for getting the Dialog Settings in 5847b3d
I have contemplated adding this as a public method to the FindReplaceAction, however I chose not to in order not to pollute API

[HeikoKlare]

@Wittmaxi Now you extract different settings sections, as each class (the action, overlay and dialog) retrieve the one according their own class instead of the one for the same class (such as the action):

IDialogSettings dialogSettings = settings.getSection(getClass().getName());

[Wittmaxi]

random fails documented in

#195
#294
#751