Support Non-WASI plug-ins

[bhelx]

Currently WASI is required for JS plug-ins. This is for a number of reasons:

1. Some js code like Math.random() and new Date() requires randomness and clocks respectively
2. The way that the plug-in is "wizened" is by passing in the JS code through stdin and parsing it in the "compile" step. So WASI is needed during compile and the program is a continuation of that.

Ideally what would come of this would be a flag that you can pass specifying you want non-wasi (or the perhaps it could be non-wasi by default). We will probably need to compile 2 versions of the "core", one with the normal wasi stuff and one neutered from any syscalls. The flag can chose which core initialize at compile time. We should also find some other way to get the code in here: https://github.com/extism/js-pdk/blob/main/crates/core/src/lib.rs#L18

Some investigation into wizer will be needed. Or we may need to disable wizening for non-wasi plug-ins.

[lukevp]

It seems like Extism is settling around some type of kernel with a consistent pattern for accessing memory locations for data passing. For the "getting code in" part, the underlying pdk could have a method that takes in a pointer to the memory where the code is, and have the rust wrapper call that method to load the code into memory for quickjs during the wizer step?

I know the newer versions of javy after this fork was started have the ability to externalize the provider quickjs as a separate module and I think they do memory passing to it currently to give it the bytecode, and not through wasi, but I could be misremembering that, it's been a while since I looked at it.