Switch to a native library for driver implementations

[alexrp]

This would have a number of benefits:

• Some unfixable race conditions relating to signals (e.g. SIGCONT) will be resolved.
• No more duplicated code between Linux and macOS.
• Significantly reduced metadata size from removing P/Invoke declarations.
• Faster managed builds and editing as CsWin32 will no longer be needed.
• Easier porting to new platforms.

The native library would probably be written in Zig or C. For this to be as painless as possible, we would need vezel-dev/zig-sdk#8 (and by extension dotnet/sdk#19929) to be implemented first.

[alexrp]

Experience from Celerity and Ruptura shows that this should be fairly straightforward to do even in the short term.

The main annoyance will be working around dotnet/sdk#19929. We need to package the compiled native libraries in runtimes/<rid> folders in the Vezel.Cathode package; we do something similar for analyzers already, so this isn't too hard. We would also need some hacks to include the native libraries when building the sample projects.

• https://github.com/vezel-dev/celerity/blob/2d1c8a070a6600f3cb2cfe01deb2cfa2a35a431d/src/runtime/core/core.csproj#L24-L38
• https://github.com/vezel-dev/celerity/blob/2d1c8a070a6600f3cb2cfe01deb2cfa2a35a431d/src/runtime/native/native.cproj#L28-L50

[alexrp]

(The native library will be written in C initially and ported to Zig once Zig reaches 1.0.)

[alexrp]

This will run into the same problem as vezel-dev/celerity#101. Or not.

[alexrp]

This will mean temporarily dropping support for musl-based systems (e.g. Alpine) due to vezel-dev/zig-sdk#83, but that's probably not the end of the world. I doubt many people would use Cathode in Docker containers or whatever.

[alexrp]

Turns out I was wrong about SIGCONT; that race condition just cannot be fixed.

https://stackoverflow.com/a/75084598