Add integration test(s) for high volume Reset calls

[AndrewSisley]

To catch stuff like #155

This probably needs a bit of prep work, so the test can be ran independently of the main suite (nightly job) so that running the core tests remains fairly quick.

[edjroz]

One thing worth flagging: the existing #155 regression test (assertResetDoesNotLeak) catches the linear-memory-growth leak in-tree by reading instance.Memory().Size() directly. But at the integration level that lever isn't available. The node/store stack pools and hides the wasm instances, so there's no clean per-instance memory size to assert against. This is signaled with process RSS.

RSS provides GC timing, allocator fragmentation, page retention, OS variance. It is only meaningful over high volume with a warm-up and generous slack robust shape is to run the high-volume Reset loop in a subprocess and sample its RSS from the parent, isolating the measurement from the test runner's own allocations. (Side note: RSS is also the only way to catch the host-side resource-cleanup leaks from #157/#158 — C/mmap memory invisible to Go's GC — so this nightly job is the natural home for those checks too.).

[edjroz]

I created a Draft PR for this, however I'm not convinced this will cover the entirety of what we'd like to evaluate here ? This one probably works as a baseline but there might be more to be added here, ideas are welcomed.