Allow plugins in fusil

[devdanzin]

For the cereggii campaign, we added cereggii specific instances and scenarios, then integrated them into fusil.

We already had added code targeting NumPy and h5py, always changing fusil's core code in a hacky way.

In discussion with cereggii's maintainer, @dpdani, we concluded that keeping this kind of code separate and interfacing with fusil as plugins and/or using hooks would work better.

To accomplish that we should:

• Investigate existing plugin frameworks and either pick one or come up with our own fusil-tailored thing. Should cover how to install/remove plugins.
• Design a clean way for external code to interface with and enhance fusil. It should provide a way for plugins to:
  • Add command-line options.
  • Add new scenarios.
  • Add new modes.
  • Add new inputs.
  • Add new argument generators.
  • Include new argument generators into the generator pool.
  • Add suppression entries as regexes to match stdout, or module, class, object, method or function names (Improve how we suppress hits #53).
  • Declare dependencies (e.g. h5py requires NumPy) and incompatibilities.
  • A way for plugins to display messages when starting and stopping fusil.
• Implement the new plugin/hooks interface, using a dummy plugin as a test case.
• Move the cereggii code from fusil into a plugin, as it's the most sophisticated addition we have.
• Do a final review of the design and polishing of the implementation based on data gathered when moving cereggii.
• Investigate moving some modes and scenarios from fusil to plugins.

These changes should come with tests (which we generally don't have in fusil), as they are likely to break the fuzzer in subtle ways.

[dpdani]

Maybe also a way to specify an ignore list for hits that are already known to be problematic?
So that fusil would not circle around the same hits?

[devdanzin]

Great idea, thank you! I've fleshed it out in #53, so we can implement it before plugins or at the same time, according to how we'll be working on these features.