Deduplicate the C definitions for static FFI exports to make the bindings easier to maintain

[rdw-software]

Some of the definitions unfortunately can't be checked by the compiler. But overall, reduces the amount of boilerplate code:

• The bindings module now contains both the exports and the cdefs for each embedded library
• Types that are used by both the C++ layer and LuaJIT share a standalone header instead of duplicating the cdefs
• They're embedded as strings (via non-portable inline assembly) and so passed to LuaJIT, which is somewhat hacky
• Opaque pointer cdefs or copy/pasted library types that can't be redefined are also stored in a separate header
• Ideally, these would be checked by the compiler and possibly redefined (aliased) so there are no conflicts (later)

More cleanup will be needed to remove the bindings member of each library, but this is far too large already.

[rdw-software]

Just a quick note for future me as to why embedding the cdefs turned out to be so overly complicated:

• The easiest hypothetical way to embed binary data is not yet implemented: https://thephd.dev/finally-embed-in-c23
• As a workaround, I tried multiple things - all of them having serious drawbacks that I'm very unhappy about
• First, I tried inline assembly... but it's not portable and it doesn't seem to be supported on MSYS (.incbin didn't work)
• Maybe more research and assembly hacking could work around this issue, but it makes the code too fragile anyway
• Next, I tried a Lua script that generates the cdefs at build time and embeds them just like all the other bytecode objects
• That does work and is reasonably fast, but it requires maintaining the script and so there's still no single source of truth
• Finally, I tried the "classical" approach of using xxd to generate binary dump headers and include them in the code
• This relies on yet another external tool that should however be present, but it's slow and complicates the build process

In short, all solutions are terrible and I'm not sure which one is the least of a headache. Give me std::embed already, will you?

[rdw-software]

I really am not a fan of this given the increase in complexity. The drawbacks simply don't seem worth it (without std::embed):

• Introduces another build dependency, on xxd (and vim as a package)
• Increases build times and complicates the configuration - need to explicitly define autogenerated header dependencies
• The glue code for all bindings needs to process the autogenerated header and convert it to the cdef string as well

Since one goal is to make sure the FFI and C++ definitions are always in sync, maybe there's a simpler way to get that benefit:

• Move the definitions used by both LuaJIT and C++ to a separate header, as proposed in this PR
• Normally include them in the bindings but continue to copy/paste it for LuaJIT until proper embeds are available in gcc/clang
• Add unit tests that read the separated header files and assert they match the cdefs, which is easy to do after the build
• Can also add assertions to detect struct size mismatches and uninitialized export table fields (NULL pointer values)
• This unfortunately doesn't ensure the opaque pointer aliases and other copy/pasted types from the library headers match
• However, the previous approach also doesn't take care of that problem and I don't think there's an easy way to do it

This would still necessitate code duplication, but if the test suite catches any discrepancy then it might not be a huge problem.

[rdw-software]

Closing for now due to the above concerns. It's too large a PR to merge as-is anyway; will split off some parts when applicable.