Optimization: no longer copy parameters for function calls

[Robbepop]

Blocked by #1598.

Currently, when calling a Wasm function from within another Wasm function, Wasmi copies the entire set of call parameters from the caller's frame to the callee's frame. This is necessary because Wasmi's stack slots are organized in a way that prevents overlapping of function frames on the stack.

The root cause for this is that function local constant stack slots are located before the function's parameters (and locals). Therefore, the Wasmi executor always has to copy the parameters as described above and put the function local constants in between. If we put function local constant stack slots after the function's parameters and locals we could actually stop copying and thus improve call performance significantly.

The reason why we currently put function local constant stack slots before function parameter and local stack slots is translation performance: function local constants are simply linearly allocated starting from -1 up to (i16::MIN+1). This way we do not need to know upfront how many function local constants are required and can just allocate them when needed. If we put them after function parameters and locals and before temporaries we'd need to do one (or both) of two things:

1. Estimate the number of function local constants that will be required and allocate this number of stack slots just for them. We need to overestimate this number which might not always work out due to intricate optimization etc.
2. Create more than enough space for plenty of function local constants and shift temporary stack slots back to not waste too much stack space. This post translation shift might be very costly.

So both approaches have weaknesses. Finding a great and efficient estimation heuristic is very difficult and shifting temporaries post translation might be extremely costly.

With this optimization in place we can unify call instructions:

1. CallInternal0 and CallInternal can be unified.
2. CallIndirect0 and CallIndirect can be unified.
3. CallImported0 and CallImported can be unified.
4. ReturnCallInternal0 and ReturnCallInternal can be unified.
5. ReturnCallImported0 and ReturnCallImported can be unified.
6. ReturnCallIndirect0 and ReturnCallIndirect can be unified.