Fix operand arity of v128.storeN_lane in GetExprArity

[aizu-m]

Found this fuzzing wasm-decompile under a debug build: a valid module whose only instruction is v128.store8_lane aborts on the value-stack assert in decompiler-ast.h Construct.

1. GetExprArity groups SimdLoadLane and SimdStoreLane together and reports both as {2, 1}.
2. store_lane pops the address and the vector and pushes nothing, so its real effect is {2, 0}; the spare result throws value_stack_depth out by one.

The decompiler models the wasm stack from this arity. The phantom value breaks the per-block invariant that the top N exp_stack items each yield one value: debug builds trip the assert, release builds fold the store into the following expression (it ends up nested inside the return). Split the case so SimdStoreLane returns {2, 0} and SimdLoadLane keeps {2, 1}. A reduced repro is added under test/decompile.