Added browser tests using wasmtime test artifacts

[jsoverson]

This PR adds the start of browser-based tests. It adds a playwright configuration to test across Firefox, Chromium, and Webkit and uses test artifacts from the wasmtime project to assert compatibility.

Only one test has been added so far (test-programs/preview1_path_open_read_write). It required some project changes that need review before moving forward.

To run tests:

$ npm install
$ npm run test:build  # clone wasmtime and compile test .wasm
$ npm run build       # compile project typescript
$ npm run test        # run tests

Change Notes:

• The initialize() function was updated to only call _initialize() if it's exported. AFAICT _initialize() is optional. This lets all reactor libraries use the same shim init logic without needing the user to inspect the exports.
• I had to pull the wasiImport types into a proper interface to keep satisfying TypeScript. This had the side effect of requiring some changes to satisfy types that would have been the source of errors before. ~Any change where obj[key] = undefined becomes delete obj[key] is due to this.~ (reverted)
• I needed to propagate the rights flags through to the Fd implementations so that fd_fdstat_get could report correct values.
• I added a dumb path_unlink_file implementation to Dir to satisfy the test wasm. It deletes the instance from the dir's contents and doesn't do anything more destructive.

[jsoverson]

@bjorn3 I hope these changes are again in the right direction. Testing could go any one of a dozen ways, and this seemed like the best cost/value.

[bjorn3]

Using wasmtime's wasi tests is a great idea. Thanks for working on this. FYI I probably won't have time to review this in the next couple of days.

Part of https://github.com/bjorn3/browser_wasi_shim/issues/7

[jsoverson]

@bjorn3 np, thanks for being willing and responsive!

[bjorn3]

I'm not entirely sure all fs_rights_base changes are correct. Would you mind pulling out all changes to the actual code except for fs_rights_base into a separate PR? Also could you add CI integration?

[bjorn3]

@jsoverson are you still interested in working on this or would you prefer if I work on splitting it up into several commits and landing it myself?

[jsoverson]

@bjorn3 sorry, this fell off my radar during a few hectic weeks. I'll jump on it this coming week.

[jsoverson]

Status: I'm going to fork wasmtime to create releases consisting of strictly the test wasm files. Getting CI setup to clone wasmtime to build the test artifacts is excessive.

[bjorn3]

You can use --filter=blob:none when cloning to tell git to only fetch the blobs that are actually necessary. For me that only takes 10s for a total download of 24MB. It can be reduced even further using a sparse checkout, but I think 10s is more than fast enough.

[jsoverson]

It's more the overhead of setting up a rust environment to build wasm files that really shouldn't change. It will dramatically extend the duration of CI tests, vs. downloading a tarball of wasm artifacts.

[bjorn3]

I see. How about caching the wasm test files in a github actions cache after they are built. And then only setup a rust toolchain for building if the cache is missing. That should be easier to keep up to date with new wasmtime versions than building locally and checking into a repo.