refactor: allow more flexibility in the types of imports/exports

[zshipko]

• Allows exports with any number of arguments and either 0 or 1 return value
  • These can be any native Wasm type: I32, I64, F32, F64
  • __arg_start is called to push a new call onto the argument stack (a global Vec<Vec<JSValue>>), then for each argument an arg function like __arg_i32 or __arg_f32 gets called, this pushes the value to the end of the vector at the the top of the stack, then when a function is called it pops the top Vec<JSValue> off of the stack to use as its arguments.
• Allows imports with up to 5 I64 arguments and either 0 or 1 I64 return value
  • Since each of these signatures need to be implemented statically (__invokeHostFunc_1_1, __invokeHostFunc_2_1, ...) , there are too many combinations to allow for any type to be used
  • Adds a new prelude function: Host.invokeFunc0 to call a host function that takes 0 arguments
  • Host.invokeFunc and Host.invokeFunc0 determine the number of arguments passed and select the proper __invokeHostFunc_$nparams_$nresults function to call
• Uses https://github.com/dylibso/wagen for code generation
• Switches to use wasm-opt instead of binaryen crate
  • We already require a binaryen installation for wasm-merge, it seems like a lot for this to include its own copy too
  • Also gets rid of that warning that was being displayed
• Backward compatible: none of the examples require adjusting, I think this change is mostly backward compatible.

[nilslice]

Awesome work. I've tested this using a Go plugin to call a JS export as a host function and it works great.

I will do more testing with it tonight.. curious if you have any specific paths that you'd like me to focus on?

[zshipko]

Thanks for taking a look!

curious if you have any specific paths that you'd like me to focus on?

I think just testing it out is the most helpful

One future improvement worth calling out is the ability to use types like string or object in the d.ts file, which would automatically get converted from an I64 parameter/result. I have started working on that, but it complicates things a little bit so it seems better to get these changes in first.

[nilslice]

Ok, ran through some more tests and re-ran the previous ones since the latest commits & everything works great!

Unless @bhelx wants to do a quick run though, this LGTM,

[nilslice]

One future improvement worth calling out is the ability to use types like string or object in the d.ts file, which would automatically get converted from an I64 parameter/result. I have started working on that, but it complicates things a little bit so it seems better to get these changes in first.

This sounds nice!!