proc: use stack machine to evaluate expressions

[aarzilli]

This commit splits expression evaluation into two parts. The first part (in
pkg/proc/evalop/evalcompile.go) "compiles" as ast.Expr into a list of
instructions (defined in pkg/proc/evalop/ops.go) for a stack machine
(defined by proc.(*evalStack)).

The second part is a stack machine (implemented by proc.(*EvalScope).eval
and proc.(*EvalScope).evalOne) that has two modes of operation: in the
main mode it executes inteructions from the list (by calling evalOne), in
the second mode it executes the call injection protocol by calling
funcCallStep repeatedly until it either the protocol finishes, needs more
input from the stack machine (to set call arguments) or fails.

This approach has several benefits:

• it is now possible to remove the goroutine we use to evaluate expression
  and the channel used to communicate with the Continue loop.

• every time we resume the target to execute the call injection protocol we
  need to update several local variables to match the changed state of the
  target, this is now done at the top level of the evaluation loop instead of
  being hidden inside a recurisive evaluator

• using runtime.Pin to pin addresses returned by an injected call would
  allow us to use a more natural evaluation order for function calls, which
  would solve some bugs function call injection has problems when the function call involves passing variables stored in registers #3310, allow users to inspect values returned by a
  call injection Function call results cannot be printed via direct address expression syntax #1599 and allow implementing some other features Support map evaluation by composite literal keys #1465. Doing
  this with the recursive evaluator, while keeping backwards compatibility
  with versions of Go that do not have runtime.Pin is very hard. However after
  this change we can simply conditionally change how compileFunctionCall works
  and add some opcodes.

[derekparker]

Initial review done.

This is amazing work!

[derekparker]

Just out of curiosity have you ran benchmarks on the existing implementation and the new one?

[aarzilli]

Just out of curiosity have you ran benchmarks on the existing implementation and the new one?

No but I don't expect it to matter much. Last time I did benchmark this code it was completely dominated by system calls.

[aarzilli]

For some reason I have pushed to my evalrefactor branch but github has decided not to pick up my changes in this PR. I'm not sure what to do, for now I'll wait and see if it fixes itself.

[derekparker]

A few more small things. This overall looks great though.

[derekparker]

lgtm