Currently, interactions with the user interface, like changing providers, opening menus or even resizing windows, take the focus away from the main views. This PR resets focus to the child (if view has no children then the view's window itself is used) of the view that had focus before the interaction took place.
It was tested by interacting with menus, changing providers, using toolbar icons, using command palette, resizing windows or widgets of the view itself that are not children windows of the main view (e.g. running a pattern and having focus return to the pattern editor when evaluation ends. or using the icons in the hex editor) and also by selecting the main view itself. To clarify this last item, if you click on the view tab (not the provider tab but the view tab itself) the focus will be restored to the child that had focused before the tab was clicked
There is no attempt to recover the active status of widgets within the window but it can be easily recovered by clicking the Tab key once. Some views, like the pattern data view, can set other views to focus depending on where they are clicked.
The implementation saves the the child sub-window in a pointer of the view and is only changed if another child is given focus. Then various UI interactions are detected with care not to change focus while the interaction occurs. The end of the interaction is detected by checking if undesired items are the ones that have focus (these undesired values only occur when the UI interaction ends) and if they are, then the focus is restored to the window that is stored in the view pointer.
When a project is loaded it is set to dirty without any changes so that
it goes through the steps that patterns with changes go through. The fix
uses a different starting step that doesn't set the dirty flags when
changing providers or loading projects.
<!--
Please provide as much information as possible about what your PR aims
to do.
PRs with no description will most likely be closed until more
information is provided.
If you're planing on changing fundamental behaviour or add big new
features, please open a GitHub Issue first before starting to work on
it.
If it's not something big and you still want to contact us about it,
feel free to do so !
-->
### Problem description
<!-- Describe the bug that you fixed/feature request that you
implemented, or link to an existing issue describing it -->
Hopefully this will help us debug the bugs that appear once ImHex
restarts a little easier.
### Screenshots
<!-- If your change is visual, take a screenshot showing it. Ideally,
make before/after sceenshots -->
<img width="372" height="182" alt="image"
src="https://github.com/user-attachments/assets/1f27443e-9eaa-465a-b545-c2bbf0b56ca4"
/>
problem occurs because there is no check for duplicate entries in the
paths vector.
The fix is implemented using the combination of two containers; a vector
to ensure the insertion order and a set to ensure the uniqueness the
entries. The set first attempts to insert the new path and uses the
return of insertion to decide if the vector needs to be updated.
