Qemu helpers & hooks refactoring

[rmalmain]

It's a first draft addressing issue #1985 and PR #1784.

Main changes of this PR:

• Rename Helper into Tool, so QemuHelper becomes EmulatorTool, QemuHelperTuple becomes EmulatorToolTuple, etc...
• Hooks have been separated into a low-level and high-level part, like for QEMU: qemu/hooks.rs contains the low-level (stateless in the rust part) struct QemuHooks and emu/hooks.rs the low-level (with a rust state) counterpart, EmulatorHooks and EmulatorTools.
• The high-level static hook variables have been centralized in the EmulatorHooks struct.
• A lot of hook-related types now have dedicated names for readability (check the create_hook_types macro)
• EmulatorTools owns EmulatorToolTuple, and Emulator owns EmulatorTools.
• The Qemu Executor now contains a ref to Emulator, not QemuHooks. The Stateful Executor now gives access to Emulator as the second argument of the harness (still through the state, I need to change this) (check the qemu_systemmode classic example to see how it changes)
• And a lot of smaller changes I probably forgot.

What remains to do:

• [ ] We still need to decide on a fitting name for Emulator that represents the fact it's a high level abstraction of Qemu.
• [ ] Not sure if we should call the EmulatorToolTuple callbacks in the executor or in the emulator run function. For now I kept it in Executor as it was before, we can easily move this now since Emulator owns the tuple.
• [ ] Change the E bound to EH bound for exit handlers to avoid the collision with the Executor generic.
• [ ] Change the QT bound to ET (or ETT?) to keep consistent with EmulatorToolTuple. Didn't do it yet to confirm EmulatorTool is a correct name.
• [ ] Should we make StatefulQemuExecutor the new default QemuExecutor with this new organization? Since it gives access to Emulator, it sounds like something we always want, even if Emulator is an empty shell only instantiated to use QEMU low-level API.
• [ ] Revamp of the Emulator builder. TypedBuilder has some flaws that make it unusable with generic members. We now need it to work correctly since Emulator will most likely be used everywhere.

[andreafioraldi]

i guess https://github.com/AFLplusplus/LibAFL/pull/1784 is superseded by this, closing

[rmalmain]

i'll merge the PR in its current state. There could be other things to add, but i believe it's already big enough like this. let's address the other points in separate PRs.