Enable direct dispatch for WASI

[rockwotj]

Direct dispatch is faster than a "normal" switch clause and it's disabled for WASI, although it works fine in wasmtime, so I'm not sure why it was disabled.

Background reading on computed gotos for interpreter loops: https://eli.thegreenplace.net/2012/07/12/computed-goto-for-efficient-dispatch-tables

[rockwotj]

Difference running this program:

function fibonacci(num) {
  if (num <= 1) return 1;

  return fibonacci(num - 1) + fibonacci(num - 2);
}

console.log(fibonacci(35));

With DIRECT_DISPATCH=1

$ hyperfine --warmup=2 -N 'wasmtime run --dir . build/qjs t.js'
Benchmark 1: wasmtime run --dir . build/qjs t.js
  Time (mean ± σ):      1.209 s ±  0.154 s    [User: 1.205 s, System: 0.004 s]
  Range (min … max):    1.138 s …  1.643 s    10 runs

With DIRECT_DISPATCH=0

$ hyperfine --warmup=2 -N 'wasmtime run --dir . build/qjs t.js'
Benchmark 1: wasmtime run --dir . build/qjs t.js
  Time (mean ± σ):      2.050 s ±  0.042 s    [User: 2.043 s, System: 0.006 s]
  Range (min … max):    2.024 s …  2.167 s    10 runs

[rockwotj]

cc: @saghul since you added WASI support in #264

[rockwotj]

(never mind it defaults to release build the results are valid)

[saghul]

Hum, I remember testing it and things not working... perhaps it was with wasmer?

[rockwotj]

Hrm I can give wasmer a try. Maybe it needs to be a compile time switch then?

[saghul]

There are other things that didn't work with wasmer, so I'm just ok landing this TBH.

[rockwotj]

Clang did add support for this, so maybe emscripten could be removed too: https://bugs.llvm.org/show_bug.cgi?id=42498

[saghul]

I guess it depends on the emsdk version?

We don't quite have a way to e2e test emscripten, but if you verify it with quickjs-emscripten then I'd be happy to land a patch!