Treat WASM_FUNCTION frames as stubs.

This is "more correct" than WASM_FUNCTION falling through the switch
over code types and using the marker on the stack which contains a bogus
value.

In the long run, there will be two kinds of WASM-related frames: frames
that cross the JS/WASM border, and internal WASM_FUNCTION frames. This
will necessitate a new StackFrame::Type, since the first kind of frame
must treat its parameters as tagged values and the second definitely
should not.

R=mstarzinger@chromium.org
BUG=

Review URL: https://codereview.chromium.org/1470353002

Cr-Commit-Position: refs/heads/master@{#32256}

src/frames.cc

@@ -436,6 +436,8 @@ StackFrame::Type StackFrame::ComputeType(const StackFrameIteratorBase* iterator,
         return JAVA_SCRIPT;
       case Code::OPTIMIZED_FUNCTION:
         return OPTIMIZED;
+      case Code::WASM_FUNCTION:
+        return STUB;
       case Code::BUILTIN:
         if (!marker->IsSmi()) {
           if (StandardFrame::IsArgumentsAdaptorFrame(state->fp)) {