Native interop: vararg support

[ForNeVeR]

@kekyo mentioned some concerns he had during building of chibicc-cil, a project sharing some purposes with Cesium.

Here's a Fediverse thread: https://mastodon.sdf.org/@kekyo/113932383592543947

In short, one of the downsides was the lack of proper native vararg support in .NET on platforms other than Windows.

Related issue in .NET runtime: dotnet/runtime#48796

If we want to enable full native interop in Cesium, then we'll have to do something about this.

My current idea would be to include a custom marshaller, or native modules, or runtime machine code emit, and support for the common call conventions.

Whatever route we take, we could consider implementing this in a shared library for the other projects to reuse if they need.

[kekyo]

The primary goal of the project to port "chibicc" to "chibicc-cil" is to reproduce in CIL the “Adding of functions with each commit” that "chibicc" expressed itself. This includes building external OSS projects such as "Git", "SQLite" and "libpng" with chibicc (around the last 10 commits).

chibicc: "Add scripts to test third-party apps": rui314/chibicc@fb49370

For this reason, I set a fairly high requirement for the implementation of the ability to achieve seamless interoperability with native libraries.

Therefore, in "chibicc-cil", "vararg" needed to work in a natural way and have a low overhead. The current implementation also works fine with variable arguments (it does not use the "vararg" function of CIL/CLR), but that was achieved by implementing it using an alternative method, and it is also costly, and it does not function as a variable argument for native libraries.

• stdarg.h related impl: https://github.com/kekyo/libc-cil/blob/362fcc9cd157b25540f73d5329add1c966311112/libgloss/stdarg.cs#L132

If I compromise on this, I could consider it as a completed form, but I would not be able to reproduce the "commit" to build the "chibicc" OSS external project in the desired form. That is the details of why I gave up on the "chibicc-cil" project.

It would have been possible to include stubs created using native libraries, but I wanted to avoid the increase in redistributable binaries, the need to include separate binaries for each architecture and target OS, and the resulting creation of unsupported targets.

This is because I felt that this was an issue that CoreCLR should support (NOTE: OldCLR and mono have no problem for "vararg" features), and because I had been reminded of this by my experience with libgit2sharp in the past, my FlashCap, and my job.

I hadn't thought about custom marshaller. I don't know if it's feasible. But if it were possible, I might have adopted that method. However, I think that the target's va_list layout is dependent on it, so I feel that there is a cost (design cost and reduced execution performance) to implementing a custom marshallar.