### Problem description
This PR addresses issue #2013 that described a cluttered Event Manager.
This is a DX issue and should not impact the users whatsoever.
### Implementation description
The changes revolve around three main points:
1. the Event Manager (`event_manager.hpp`) was split into four
categories: GUI, Interaction, Lifecycle, and Provider, and two types:
Events, and Requests. This results in the following files:
- `events_gui.hpp`
- `events_interaction.hpp`
- `events_lifecycle.hpp`
- `events_provider.hpp`
- `requests_gui.hpp`
- `requests_interaction.hpp`
- `requests_lifecycle.hpp`
- `requests_provider.hpp`
2. Every event and request now has its own piece of documentation, with
a `@brief`, accompanied by a longer comment if needed, and gets its
`@param`s described.
3. The old `event_manager.hpp` import was removed and replaced by the
correct imports wherever needed, as to reduce spread of those files only
to where they are truly useful.
### Additional things
The commits have been split into (chrono-)logical steps:
- `feat`: split the Event Manager, and replace the imports
- `refactor`, `chore`: make various small changes to match the required
structure
- `docs`: add documentation for events and requests
Hopefully, this will help to review the PR.
*Note: Beware of very long rebuild times in between the commits, use
them sparingly! The Actions will ensure this PR builds anyways*
Closes#2013
---------
Signed-off-by: BioTheWolff <47079795+BioTheWolff@users.noreply.github.com>
Co-authored-by: Nik <werwolv98@gmail.com>
This PR adds a test architecture to be able to test plugins
Main infrastructure done by @WerWolv
---------
Co-authored-by: WerWolv <werwolv98@gmail.com>
### Problem description
Currently, the providers use the method `isSavable()` to determine both
if they can use "Save" or "Save as".
This behaviour is problematic because some providers may need to be
saveable but not saveable as: for example the view provider. The
original provider may not allow to be saved.
### Implementation description
I separate these two behaviour by creating another function:
`isDumpable()`, that return true by default but can be overridden by the
provider to return false, if the provider should not be dumped in any
way.
### Additional things
While I was at it, I also marked "export" operations as needing the
"dumpable" flag. That way, we can't accidentally export the whole
address space of a process as base64.
I also added documentation for these some functions in Provider
* feat: Initial implementation of an Intel Hex provider
* fix: Reading of bytes from intel hex files
* lang: Added localization for new provider
* ui: Only show file name in intel hex provider name
* feat: Added Motorola SREC provider
