Do not free memory that needs to persist in the host

[gmlewis]

As documented in the #js-sdk Discord channel, I believe that the Go PDK should not be freeing memory that needs to persist in the host.
This PR addresses this issue.

[gmlewis]

I'm now wondering if OutputJSON should have a call to Free() for its AllocateBytes().
Also, RemoveVar should probably free its AllocateBytes.

In fact, I'm now thinking that the Memory objects created in the SetVar and SetVarInt might need to be retained and exposed to the PDK user so that they can then later Free them when necessary.

Additionally, I'm thinking that the MoonBit PDK also needs to do similar things... basically giving more memory control to the PDK user.

[nilslice]

Perhaps I'm missing its definition, but where does mem come from?

[gmlewis]

Yikes, I should not have done that in a hurry. I'm on a flight now but will fix this later tonight.
Sorry.

[nilslice]

If we'd retain memory that needs to be accessed by the host elsewhere, shouldn't that also be true here?

[gmlewis]

So my thought here was that the host would output the information immediately and the memory could be freed. That seemed to work in the MoonBit PDK but this is one reason why I think a suite of conformance tests would be fantastic... To help answer questions like this one.

[gmlewis]

I've fixed the error and run the tests, and it all appears to work now. Sorry about that.

$ make example
tinygo build -o example/tiny_countvowels.wasm -target wasi ./example/countvowels
tinygo build -o example/tiny_http.wasm        -target wasi ./example/http
tinygo build -o example/tiny_reactor.wasm     -target wasi ./example/reactor
GOOS=wasip1 GOARCH=wasm go build -tags std -o example/std_countvowels.wasm ./example/countvowels
GOOS=wasip1 GOARCH=wasm go build -tags std -o example/std_http.wasm        ./example/http

$ make test
extism call example/tiny_countvowels.wasm count_vowels --wasi --input "this is a test" --set-config '{"thing": "1234"}'
{"count": 4, "config": "1234", "a": "this is var a"}extism call example/tiny_http.wasm        http_get     --wasi --log-level info --allow-host "jsonplaceholder.typicode.com"
{
  "userId": 1,
  "id": 1,
  "title": "delectus aut autem",
  "completed": false
}

extism call example/tiny_reactor.wasm read_file --input "example/reactor/test.txt" --allow-path ./example/reactor --wasi --log-level info
Hello World!

extism call example/std_countvowels.wasm _start     --wasi --input "this is a test" --set-config '{"thing": "1234"}'
{"count":42,"total":21000000,"vowels":"aAeEiIoOuUyY"}

extism call example/std_http.wasm        _start     --wasi --log-level info --allow-host "jsonplaceholder.typicode.com"
{
  "userId": 1,
  "id": 1,
  "title": "delectus aut autem",
  "completed": false
}

[gmlewis]

Hmmm... that "total":21000000 looks really suspicious... Investigating.
EDIT: never mind. That value is directly in the example code.

[zshipko]

It seems like this is actually related to how the js-sdk has implemented var storage, I just opened a PR here: extism/js-sdk#71

Some of these other changes seem good though so I think this could still be worth merging with some small modifications

[zshipko]

We should add this back since extism/js-sdk#71 addresses the root of the issue