Allow for creating C interfaces for Rhombus code

[slaymaker1907]

Racket/Rhombus is all about languages cooperating with one another, but one thing that currently seems limited is creating a C interface for other code to call into Racket code. This obviously would require running a Rhombus VM, but ideally one should be able to write Racket functions for the purpose of exposing an API to C code (similar to how one can do so in Rust and C++).

Having a C interface to a Rhombus library would be valuable in cases where an existing code base wants to use Rhombus for one particular component such as a game engine with Rhombus scripting.

In order for this to work, it will likely be necessary to define a function pointer type for any Rhombus function you wish to expose which should not be a huge effort. Perhaps a new provide form could be added for the specific purpose of attaching a function type to a function.

The larger problem is how to expose the Rhombus function to non-Rhombus code. Arguably the simplest way would be to require users to provide a C function name when exposing a function to C. However, I think a cleaner way would be to expose a C function rhombus_func_t rhombus_resolve(rhombus_context_t ctx, rhombus_desc_t desc) where the context represents a Rhombus VM and "rhombus_desc_t" is an opaque value describing a Rhombus function. It is not just a string so that you can optionally provide a function pointer type on the C side (assuming a similar API as Rhombus exists in C which Rhombus provides to describe these types) so that C can call into Rhombus code not originally written with a C ABI in mind.

typedef struct
{
  void* cfunc;
  cfunc_ctx_t cfunc_ctx;
} rhombus_func_t;

Note above that "rhobmus_resolve" returns two values. This is to allow Rhombus to reuse one function pointer for multiple Rhombus functions if desired. So if a Rhombus function had the C type "int (*func) (int, int)", "cfunc" would actually be of type "int (*func) (cfunc_ctx_t, int, int)".

I'm not sure it is necessarily a good idea to allow calling Rhombus code not written with a C interface in mind from C since it may impose unwanted limitations on the Rhombus VM going forward as far as how it represents values. Notable complexities would be how to create Rhombus types like lists or how to handle keyword arguments which is why I think requiring opt-in on the Rhombus side to be a good idea.