FFI support

[melkyades]

We need to support calling C code (ideally C++ too but that seems to be a much harder problem).

This requires designing and implementing at least two parts, one on the VM side (the actual call), and another in the image side (the bindings). Consider this just a starting point to iterate and improve the design.

The constraints I'm thinking of are the following:

• We want something small and simple, with the least possible amount of dependencies.
• It must support POSIX, windows and mac.
• We prefer having as much things as possible in Smalltalk, rather than depending on things outside of our control. Of course, this is as long as possible. For example, using libffi is a welcome solution as a no-brainer implementation on the VM side (even though we'd like to have in-smalltalk support instead).
• It is not an option depending on things such as clang for using FFI (specially at runtime). However, it could be useful to have tools that simplify binding generation. Again, ideally we prefer things implemented in Smalltalk (i.e. a binding generator using a C parser written in St), but as they are optional tools, we could support different things (like another binding generator that uses clang).
• It is not an option on depending on C code being compiled in a particular way (i.e. to have dwarf info). Optionally using that info for binding generation or validation if desired is ok.

VM side

For the cpp vm, using libffi could be a simple option, as an FFI primitive can take the args from the st stack and pass them to libffi. For the LMR, it looks more difficult, as the LMR would need itself to call libffi, which falls into an infinite recursion. We would need some bootstrap mechanism to be able to call libfii, or just implement a libffi in our own (how hard could that be?™).

Image side

On the image side we will have a model of the things outside the image: objects for external memory, C functions, C structures, C types. I personally like the idea of doing most FFI in the image side (i.e. creating external objects and preparing things for the call).

For bindings, I'd go for the traditional design where each C library is a subclass. Each C function inside it is a method with a C prama. Something like:

PochosLibrary class>>name 
    ^'Pocho'

PochosLibrary>>hello: aString
    <cdecl: void hello>

PochosLibrary>>sumFloat: aFloat and: anotherFloat
    <cdecl: float hello (float float)>

Notice the arguments are implicit as long as they are pointers (I'm not sure that would work on all platforms).


Inspiration
----

We are not the first to do this, so we are open to take inspiration from other projects, to gather nice ideas, and still strive to have our own design, Smalltalk usually allows things to be _simpler_.

just a few projects around:

- libffi - https://github.com/libffi/libffi - [(docs)](https://gensoft.pasteur.fr/docs/libffi/3.3/libffi.pdf)
- ctypes (python) - https://docs.python.org/3.12/library/ctypes.html
- ruby ffi - https://github.com/ffi/ffi
- jni - https://en.wikipedia.org/wiki/Java_Native_Interface
- panama (java) - https://openjdk.org/projects/panama/
- pharo uffi - https://books.pharo.org/booklet-uffi/
- dart ffi - https://dart.dev/interop/c-interop

[melkyades]

an initial implementation effort has been started, see #90

[melkyades]

And now it is merged. We can continue iterating from there.