Running C extensions natively

[eregon]

We want to experiment with running C extensions natively instead of on Sulong.
Similar to what GraalPython did for 23.0.
We might still run libtruffleruby on Sulong, or at least initially we would because this is much easier.

• This should improve compatibility with bigger extensions such as grpc which are proving difficult to run on Sulong due to the very large amount of C/C++/etc code they run.
• This would eliminate warmup for native extensions.
• It will speed up native compilation by not needing bitcode
• It can reuse the compiler toolchain of the host system, which means we would not need the llvm toolchain anymore (saves disk space) if this mode is good enough to replace running C extensions on Sulong
• Peak performance might be lower for some extensions which benefit from fast C->Ruby and Ruby->C calls, due to having to create handles for every Ruby->C call and going through NFI/JNI/Panama for C->Ruby calls. OTOH, the native code in the extension might run faster as Sulong e.g. reimplements vector instructions. We will need to benchmark this.
• Some struct accesses cannot be virtualized by Sulong anymore and so these structs likely either can't be supported or we need to allocate a native struct and copy there (for read-only fields, because writing to them would have no effect). Hopefully very few extensions rely on direct struct access. The Ruby C API seems to have very few exposed structs.

[eregon]

I made a lot of progress on this this week and now all C API specs pass when running extensions natively (i.e. not on Sulong, except for libtruffleruby itself)!
WIP in #3286, it also needs changes in NFI.

[eregon]

One change is that loading extensions might fail early with undefined symbol like:

(currently)
$ jt ruby -ropenssl -e0
... openssl.so: undefined symbol: rb_during_gc) (RuntimeError)

So while with Sulong we could afford to not define functions of the C API we did not implement yet, we have to define them with native to just load the extension, even if we just rb_tr_error() or so inside. That's rather unfortunate because then an extension cannot easily know if a function is available or not using have_func anymore.

EDIT: actually we can solve this by using RTLD_LAZY instead of the default RTLD_NOW.
That seems a good solution and avoids defining a bunch of functions for Ripper and other extensions.

[eregon]

• Some struct accesses cannot be virtualized by Sulong anymore and so these structs likely either can't be supported or we need to allocate a native struct and copy there (for read-only fields, because writing to them would have no effect). Hopefully very few extensions rely on direct struct access. The Ruby C API seems to have very few exposed structs.

The main one here is struct RBasic.
Reading the klass field can be replaced by RBASIC_CLASS (also exists on CRuby).
Accessing the flags field can be replaced by RBASIC_FLAGS/RBASIC_SET_FLAGS (do not exist on CRuby).
This can be used to define these macros in any case:

#ifndef RBASIC_FLAGS
#define RBASIC_FLAGS(obj) (RBASIC(obj)->flags)
#endif

#ifndef RBASIC_SET_FLAGS
#define RBASIC_SET_FLAGS(obj, flags_to_set) (RBASIC(obj)->flags = flags_to_set)
#endif

There are also various flags macros like RB_FL_TEST which exist on CRuby and are supported on TruffleRuby before & after. In general native extensions should not use RBasic flags so this should have little impact.

The reason accessing RBASIC(obj)->flags is no longer supported is because there is no way to implement it, because writing to the flags would just be ignored, because we store flags in a different way, e.g. the frozen flag is stored in the Shape, not in native memory.