Memory arena for Go-interop

[emil14]

The Problem

While working on #915 in #949 it became clear that memory arena might be a good fit for this design. There're two reasons for this:

1. Neva components are called from Go code like sub-programs rather than co-routines (using call/return semantics instead of send/receive)
2. For each call we spawn neva runtime instance with all the runtime function goroutines needed

These are current design constraints that allow to make it work easily. However it comes with the cost and while there was no benchmarks it wouldn't be surprise if that generates a load for garbage collector.

The Solution Proposed

Solution could be memory arena. We pre-allocate memory before call Neva component and then free it, after it finishes.

Of course it's not obvious how much memory to pre-allocate but that's something to discuss.