This is a first pass at implementing support for [WASI](https://wasi.dev/).  It
adds a new `TeaVMTargetType` of `WASI`, which is mostly the same as
`WEBASSEMBLY` except it generates a module suitable for execution by a
WASI-compatible runtime such as
[Wasmtime](https://github.com/bytecodealliance/wasmtime).

Currently supported features:

- A simple allocator for supporting the component model [canonical
  ABI](https://github.com/WebAssembly/component-model/blob/main/design/mvp/CanonicalABI.md)
  calls
- CLI argument marshaling
- Standard in/out/err
- Filesystem operations and I/O
- System clock

See tests/wasi/src/main/java/wasi/Test.java and tests/wasi/test.sh for examples.

Not yet implemented:

- Networking (i.e. sockets)
- Environment variables
- System random numbers
- Process exit, yield, etc.
- [DWARF](https://dwarfstd.org/) debugging support
- Better logging of uncaught exceptions

Note that the current implementation is probably overly paranoid in that all
pointer arguments passed to WASI functions are allocated by the aforementioned
allocator rather than on the Java heap.  I've done this because I'm not clear on
when TeaVM guarantees that object address will not change.  Thus I've assumed
that they could change at any time whatsoever, which is probably not true.

Also note that the filesystem implementation currently throws generic
`IOException`s and `ErrnoException`s rather than those specified by the standard
(e.g. `FileNotFoundException`).  Additional work will be needed to throw the
correct exception based on the `errno` value.

The main goal of this PR is to start a discussion about WASI support in TeaVM
and answer questions such as:

- Is WASI support a reasonable goal for the TeaVM project?
- If so, is the approach of this PR roughly correct, or are significant changes needed?
- What other features are missing to make this useful?

Signed-off-by: Joel Dice <joel.dice@fermyon.com>

My previous commit was based on the assumption that objects allocated on the
Java heap could be moved by TeaVM at any time.  It turns out TeaVM will not move
objects which are referenced by stack variables, so we can use those instead of
`malloc`ed buffers.

Signed-off-by: Joel Dice <joel.dice@fermyon.com>

Per review feedback, this removes `TeaVMTargetType.WASI` and makes
`TeaVMTargetType.WEBASSEMBLY` generate a WASI module unconditionally.  Such
modules won't run in a browser without a polyfill, which I plan to add in a
later commit.

Along the way, I noticed the `Console` intrinsics weren't working properly and
fixed them.

Finally, this adds a new `WasiRunStrategy` which runs the full TeaVM test suite
using either Wasmtime or Wasmer.  You can try it by running the following from
the test directory:

```
mvn -e install \
  -Dteavm.junit.js=false \
  -Dteavm.junit.js.runner=none \
  -Dteavm.junit.wasm=true \
  -Dteavm.junit.wasm.runner=wasi-wasmer
```

Specify `-Dteavm.junit.wasm.runner=wasi-wasmtime` to use Wasmtime.

Currently many of the tests are failing, but I haven't had a chance to
investigate yet or compare the results to the same tests running in a browser
using an unmodified TeaVM.

Signed-off-by: Joel Dice <joel.dice@fermyon.com>

Signed-off-by: Joel Dice <joel.dice@fermyon.com>

Signed-off-by: Joel Dice <joel.dice@fermyon.com>

Previously, TeaVM used imported functions for timezone resolution, char case
conversion, and floating point tests.  Since WASI doesn't support any of those
things, we implement them in Java as best we can.  Floating point tests are
easy; timezone resolution will have to wait for
WebAssembly/WASI#467 (we hard-code UTC for now); case
conversion can be done entirely in Java, although I've only handled ASCII
characters in this commit.

Signed-off-by: Joel Dice <joel.dice@fermyon.com>

Signed-off-by: Joel Dice <joel.dice@fermyon.com>

One of the tests had been running for 90 minutes when I gave up on it.  Now we
time out any tests that takes longer than 5 minutes.

Signed-off-by: Joel Dice <joel.dice@fermyon.com>

Signed-off-by: Joel Dice <joel.dice@fermyon.com>

A previous commit provided stub implementations of `getNativeOffset`,
`toUpperCase`, and `toLowerCase`.  This reverts that change and instead uses the
JS versions in the browser.  It won't work in a WASI runtime without providing
the extra imports to the module, but there's currently no way to get the local
timezone in WASI, and I'm not yet ready to take on a proper implementation of
`toUpperCase` and `toLowerCase`.

Signed-off-by: Joel Dice <joel.dice@fermyon.com>

Signed-off-by: Joel Dice <joel.dice@fermyon.com>

This uses https://github.com/bjorn3/browser_wasi_shim to emulate WASI features.
Note that I had to change the API for TeaVM `main` since `browser_wasi_shim`
requires that CLI arguments are known before the module is loaded.

Signed-off-by: Joel Dice <joel.dice@fermyon.com>

Signed-off-by: Joel Dice <joel.dice@fermyon.com>

Signed-off-by: Joel Dice <joel.dice@fermyon.com>