Add alternative emulation through unicorn engine

[ks0777]

This PR adds the unicorn emulation engine to archie. It can be enabled by passing the --unicorn flag to the controller. With this option enabled, archie will emulate the experiments with the unicorn engine instead of QEMU. The (pre-)goldenrun is still emulated with QEMU which is necessary in order to obtain a state from which we can start our experiments from.

The alternative emulation mode was implemented in a seperate Rust library and integrated into archie with minimal changes to the faultclass and controller scripts. This allows for easy reuse of the filtering and processing functions that have previously been implemented for the experiment data returned by QEMU.

[ks0777]

Waiting for unicorn-engine/unicorn#1812 to be merged. We need the additional Rust bindings in order to clear the tb cache after modifying instructions during a fault

[e-shreve-ti]

This is a nice addition! If I may, here is a suggestion to increase the flexibility of the solution toward supporting additional emulation engine support (even beyond qemu and unicorn):

• Instead of a --unicorn argument to controller.py, do the following:
  • Either change the --qemu option to --emu now or add an --emu option as an alternative to --qemu (they would do the same thing). The idea of adding --emu without replacing --qemu would be to deprecate --qemu toward only having --emu in a future update.
  • The json file passed to --emu could then provide either a "qemu" or a "unicorn" member. The value of those members would be the path to the emulator binary (just as the "qemu" member is today.) However, if "qemu" member is provided then qemu is used, if "unicorn" member is provided then unicorn is used. Instead of passing the new bool value of unicorn_emulation to controller(), the controller() function can then just look for the "unicorn" member and set its internal boolean unicorn_emulation based on that. This also avoids the confusion for users of passing the path to unicorn in the "qemu" member.
  • Update the "additional_qemu_args" member of the config.json to be called "additional_args", this will be clearer to users long-term.

The idea here is that if an additional emulation engine is added in the future, then the framework is already setup for that. The controller() function would just be modified to look for a new "otheremulatorname" member in the config file and take actions as needed there. It also means users don't have to match command line parameters to controller.py with the contents of the emulation JSON file-all the settings are in the JSON file.

[ks0777]

Thanks for your suggestion! Including, the choice of emulation engine into the configuration files sounds a like a good idea. Note that when using Unicorn, the pre-goldenrun is still performed using QEMU in order to ensure compatibility with more firmware since Unicorn can not handle any hardware related functions. Unlike QEMU, the unicorn engine is invoked through a Python module which wraps a Rust library. The required data for the initialization of Unicorn is retrieved from the pre-goldenrun. Hence, there is no need to supply additional arguments or a path to the emulator binary for Unicorn. This may change in the future if we ever decide to add addtional emulation engines, but for now these arguments only apply to QEMU.