[ArcRuntime] Add runtime library implementation for arcilator

[fzi-hielscher]

Tackle #8484 again: This PR adds a runtime library for arcilator which should provide common support functionality for both JIT and AOT compiled models. It doesn't do much at this point. The relevant functions for now are:

• allocInstance: Allocates and initializes the state for an instance of a hardware model and the associated context for the runtime library.
• deleteInstance: Tears it down again.
• onEval: Housekeeping before each step of the model. At the moment just increases a counter.

Among other things, this should hopefully provide a more solid base for VCD tracing than the haphazard implementation in #8986.

An unfortunate amount of complexity comes from the various environments which the library has to interact with. Essentially, it has three interfaces:

• The "internal API" interfacing with the compiled model. This is declared in IRInterface.h.
• The interface to the arcilator tool for explicitly binding it to the MLIR Execution Engine. This is declared in JITBind.h.
• The "public API" to interface with the simulation executables of AOT compiled models. This is declared in ArcRuntime.h and needs to be shipped to users. It is deliberately kept in pure C to allow interfacing with non-C++ environments.

The whole linking strategy for the runtime library is a bit mad, but based on my previous experience it is the least likely to break variant I could come up with:

• For Linux/macOS a static library gets built and shipped. This should not get in the way of the musl build and might provide some opportunities for LTO.
• For Windows we build a dynamic library. We could provide a static library, but due to the way the Windows C runtime works, a static library built in Release mode cannot be linked against a Debug mode build and vice-versa. So we probably would have to provide both.
• For JIT execution a variant of the library gets statically linked into the arcilator executable. Technically, the MLIR Execution Engine should be able to bind the exported symbols of the library to the IR without additional effort. However, form my experience this is error prone and relies on obscure linker behavior. So instead the symbols are deliberately hidden from the Execution Engine and instead bound explicitly via function pointers.

This PR is the first of a series and only contains the runtime library itself. #9357 does the necessary changes on the MLIR side and #9358 makes it usable.