[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   1h 43m 28s ⏱️ - 4m 30s
 7 714 tests ±0   7 485 ✅  - 1  228 💤 ±0  1 ❌ +1 
24 303 runs  ±0  23 555 ✅  - 1  747 💤 ±0  1 ❌ +1 

For more details on these failures, see this check.

Results for commit a3b0aa4. ± Comparison against base commit 4fbbe1b.

♻️ 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

[HeikoKlare]

Failing test is unrelated and documented: #926