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 do just that. 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
• Explore providing operation batches to simulators

[Copilot]

Copilot wasn't able to review this pull request because it exceeds the maximum number of files (300). Try reducing the number of changed files and requesting a review from Copilot again.