VM is not properly released back to sync pool

[piux2]

          This will not zero the m.Ops and m.Values slice. 

Originally posted by @piux2 in #894 (comment)

The opZeroed and valueZeroed arrays are fixed in size with a length of 1024. However, m.Ops and m.Values are slices, and their length could far exceed 1024. The copy() function, in this context, only zeroes out the first 1024 elements of the slice, leaving the remainder unchanged.

Here's a sample code that illustrates this behavior:
https://go.dev/play/p/JoShYG2Q8lf

Given the above, I don't see a significant advantage to zeroing out the entire slice.
A more effective approach might be to set the slice to nil, allowing the Go runtime to garbage collect the underlying arrays.

Here's why:

The VM machine operates within a transactional context, with its lifecycle managed by this context. The efficiency of interactions with gno.land is governed by the time it takes to process requests and responses within this context. The Go runtime handles the allocation and management of underlying slice memory far better than the manual methods we're attempting here.

Furthermore, there's an oversight: only m.Ops and m.Values are being considered for reset. The machine also retains m.Exprs, m.Stmts, m.Blocks, and m.Frames, all of which are slices. It's crucial to release these as well.

[moul]

@mvertes @peter7891