rework hooks in pluginex class

[1ndahous3]

This improvement implements storing hooks in the pluginex base class, so that almost all plugins no longer need to store hook objects (inherited from BaseHook) in their own containers.

Hooks were typically stored in plugin members in two ways:

• separate pointers (std::unique_ptr<libhook::SyscallHook> some_func_hook;)
• map (std::map<uint64_t, std::unique_ptr<libhook::ReturnHook>> ret_hooks with the key calculated by the make_hook_id()), which also breaks some plugins (Hooks on nested functions are broken #1712)

Hooks are now by default saved in the pluginex::hooks map with a unique key (hook address), so there are additional methods to remove or register (i.e. take ownership of an existing hook previously created with the save = false flag) hook.

So, the key changes:

• pluginex methods for creating hooks (eg createReturnHook()) now return raw pointers (instead of 'std::unique_ptr') and have a bool save flag (true by default).
• removed custom maps and std::unique_ptrs in varoius plugins.
• now return hooks are removed from their callbacks (*_ret_cb()) using the backward reference in params (this->remove_hook(params->hook_);).
• if the plugin needs to perform more complex manipulations with the hook, it can store the raw pointer during creation to later delete it (by passing the pointer to plugin->remove_hook()) or just read the information via dereference.
• the plugin can pass the bool = false flag, then it is responsible for storing/deleting the hook (usually in this case the raw pointer is instantly wrapped in std::unique_ptr).

Also made a small refactoring related to containers in different classes (std::map -> std::unordered_map, std::vector -> std::unordered_set, etc.).

[drakvuf-jenkins]

Can one of the admins verify this patch?

[tklengyel]

This PR will need a rebase. Closing it for now as there hasn't been any progress in months, feel free to reopen.