The callback is now routet to the Ractor, that created the FFI::Function .
Within this Ractor a new ruby thread is created to execute the Proc, like before.

No need to share per thread data object accross ractors.

Ractor-local custom typedefs are used now, since global writable typedefs aren't compatible with Ractor isolation.

Now the builtin typedefs are frozen and available for all Ractors.
But all custom typedefs are only per Ractor.

Actually the global typedefs already were useable in Ractors, if they are resolved in C code.
This is because the C code doesn't check the Ractor boundaries.

since there's no need to modify it later on

It is incompatible to our usage of instance variables by the Struct class.

…o be attached

This allows to freeze the FFI::Function immediately, so that it is shareable by Ractor without the need to freeze the module explicit.
To make it shareable the typedef hash used for variadic functions is duplicated and made frozen.

This creates a small compatibility issue:
Only typedefs defined above the variadic function can be used by that function.
If a typedef is created after the definition of the variadic function, then this typedef can no longer be used as parameter to that variadic function.

Also fix the retrieval of simple (non-struct) global variables per #attached_variables.

Closes ffi#975

The term "return_type" is already used in Truffleruby and sounds better to me.
On the other hand the term "result_type" was only used in C-ffi as FunctionInfo#result_type, which is an internal class only.

Shareable instance variables on modules are essential for most Ractor specs.
They were introduced in ruby-3.1.

And remove support for older rubies.

…ary definitions Ractor usable

Freeze objects which are immutable from the start are now freezed.
This allows these objects to be used by Ractor without make_shareable.

This partially reverts commit 4fc6a8c in such a way, that functions are stored in a module variable @ffi_functions.
Enums are implemented per FFI::Library not per attached function.
To make them shareable they would have to be copied and freezed per function.
This would increase memory footprint for the sake of Ractor support.

IMHO it's better to mark the module explicit as finished by .freeze to allow its use in a Ractor.
This also enables querying the enum definitions from a Ractor.

Using a Hash instead of per-function variables allow to use foo! and bar? methods as wished in ffi#971.

Fixes ffi#971

of commit e987ab5

..until necessary native methods are added.