[interpreter] Begin implementation of a new interpreter

[tlively]

The current interpreter used in wasm-shell, the fuzzer, and
optimizations like precompute works by recursively walking the
expression tree and computing expression results as it goes. This kind
of recursive interpretation is not going to work for stack switching,
since stack switching requires stashing context away and restoring it
later. The recursive interpreter stores intermediate values on the
native stack and returns early to implement control flow, so there is no
way to suspend a computation and resume it later.

To support stack switching and support other use future interpreter use
cases such as running the full spec test suite and fuzzing multithreaded
programs, introduce a new interpreter that is not recursive and does not
store intermediate state that needs to persist beyond the execution of a
single instruction on the native stack. The new interpreter works by
iterating through instructions and visiting them one at a time in a
loop. The visitor pushes and pops values from a stack and signals
control flow via its return values. Control flow transfers are handled
by the main interpreter loop, so expressions are only visited when they
are actually executed. This design will not only support stack switching
and other features better than the old interpreter, but it will also
significantly decrease the amount of code in the interpreter.

In addition to the core interpreter loop, also lay out a skeleton of the
execution context for the new interpreter, including a call stack and
store. The code contains several TODOs describing how these runtime
structures will need to be extended to support interpreting the full
spec test suite, including the ability to interpret over multiple linked
instances at once.

Most of the actual interpretation of expressions is left as future work,
but the interpretation of Const expressions and i32.add is implemented
and tested in a new gtest file to demonstrate it working end-to-end. One
of the first milestones for the new interpreter will be getting real
spec tests running with it, at which point the gtest file can be
removed.