feat!: Use struct exports for all plugin types, separate error model and simulator

[jake-arkinstall]

Presently, all components expose C functions. We then load those up and invoke them as-if they were struct fns.

This causes some painpoints. A relatively minor example is that support for optional functions is informal at best.

A much more prevalent example is that we have reason to move ownership of simulators away from the error model, such that we may track communication between the two - the cleanest mechanism for this is to provide the simulator to the error model through dependency injection.

To this end, we need an FFI-friendly concept of "an instance pointer and a bag o' methods", such that we can export a simulator as a C struct and pass that to the error model.

If we are to go down that route, it makes a lot of sense to make this representation the primary C interface for plugins, including at the dylib level.

In this PR, we attempt that. As there was a lot of repetitive work, it was done with the help of Codex, so expect some level of fluff. Plugins expose a struct instance containing function pointers. This can then be consumed, potentially wrapped, and then re-exposed for the purpose of dependency injection over a C FFI boundary.

This is not complete work as of yet. To demonstrate the value of it, I wish to perform the following additional work:

• Provide the ability to add event hooks around error model <-> simulator interactions
  • Provide error model outputs in selene_core.Trace for noise analysis
  • Provide simulator timing information in a selene_core.Trace for perf analysis
• Demonstrate the compatibility of plugins if Selene's interface changes to:
  • Add new optional functionality
  • Add new required functionality
  • Remove optional functionality
  • Remove required functionality
• Explore providing operation batches to simulators
• Explore giving error models and simulators the same interface, allowing for:
• Explore passing an (error model, simulator) pair to the runtime via dependency injection, potentially allowing for the runtime to issue commands from a separate thread