Interpreter: callProcedure with return values

[ailrst]

This refactors the interpreter entrypoint around the function callProcedure, which returns a future which immediately evaluates the call to the procedure and returns its return values (if the procedure has out-parameters defined). The goal here is to make it easier to write tests such that you can simply write a procedure literal, and evaluate it, and assert the return value.

This also lays the groundwork to cleanup the implementation of intrinsic functions. Currently we have intrinsics that expect to read/write global registers, so calls with formal parameters are stored to the expected global variables before the call, and read back after. This can be substantially cleaned up (and some indirection removed) by instead standardising intrinsics on the parameter form, and if the IR doesn't have parameters then storing the return values to the appropriate registers (i.e. the reverse).

This also simplifies the return value handling in the interpreter by putting it back in the DirectCall, because now we can immediately get the state & return value after the call. This is possible because callProcedure is evaluating the procedure immediately through the call to evalInterpreter(f, interpretContinuation(f)). (Recall our general approach to dealing with statemonad closures producing stack overflows is to perform eval at each interpreter step (ir statement), this is now additionally doing an eval at each call). I'm not sure what the downside to this is but it is not great.