`longjmp` can be called to raise `NoMemoryError` or to trigger GC when
`malloc` fails to allocate memory in `ruby_xmalloc` family. In such
case, `malloc` call in `longjmp` will fail again, and Asyncify unwinding
operation corrupts the memory space by using the failed pointer as
Asyncify buffer. This commit uses statically allocated buffer to avoid
such situation.

[wasm] Fix Asyncify loop exit condition for normal return

Stop calling `asyncify_stop_unwind` when the main function returns
without any unwinding. In the era when Asyncify buffers were allocated
on the stack, the `top` and `end` fields were remained in the stack
space even after the main function returned, so buffer-overflow check in
the `asyncify_stop_unwind` function passed. But now, the `top` and `end`
fields are part of the jump buffer allocated on the heap and they are
deallocated with `free` when the corresponding VM tag is popped. So, the
buffer-overflow check in the `asyncify_stop_unwind` function failed when
the main fuction returned without any unwinding, and we have to break
the asyncify loop before calling `asyncify_stop_unwind`.

Related commit: https://github.com/ruby/ruby.wasm/commit/bc46b12b127e4b6625a100f373504ed5ea45ae66

The Ruby built for wasm cannot be execute without a WebAssembly runtime.

```
$ ruby-wasm32-wasi/usr/local/bin/ruby -e 'puts "a"'
bash: ruby-wasm32-wasi/usr/local/bin/ruby: cannot execute binary file: Exec format error
```

Because the Ruby's file type is different from the one built normally, that is
the `/usr/local/ruby-3.2.0-preview2/bin/ruby` below.

```
$ file ruby-wasm32-wasi/usr/local/bin/ruby
ruby-wasm32-wasi/usr/local/bin/ruby: WebAssembly (wasm) binary module version 0x1 (MVP)

$ file /usr/local/ruby-3.2.0-preview2/bin/ruby
/usr/local/ruby-3.2.0-preview2/bin/ruby: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=a37822085e285c0971159982e7642dda88cea606, for GNU/Linux 3.2.0, with debug_info, not stripped
```

fiber machine stack is placed outside of C stack allocated by wasm-ld,
so highest stack address recorded by `rb_wasm_record_stack_base` is
invalid when running on non-main fiber.
Therefore, we should scan `stack_{start,end}` which always point a valid
stack range in any context.

We no longer need to use older version of binaryen since the blocker
issue has been resolved https://github.com/WebAssembly/binaryen/issues/4401