We will need more Asyncify space for the upcoming namespace changes
as it will introduce more local variables and conditional jumps in
asyncify'd functions.

we had been using a stub weak definition of `mprotect` in wasm/missing.c
so far, but wasi-sdk 23 added mprotect emulation to wasi-libc[^1], so the
emulation is now linked instead. However, the emulation doesn't support
PROT_NONE and fails with ENOSYS, so we need to avoid calling mprotect
completely on WASI.

[^1]: https://github.com/WebAssembly/wasi-libc/commit/7528b13170462c82e367d91ae0ecead84e470ceb

* Fix WASM bullet/code indentation

* Use `console` code highlighting where appropriate

… which handles the prefix `$` correctly.

* Migrate feature proposal template to MarkDown

* Set language on code blocks

`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