wasip1: fix file open modes used by wasi-libc

[achille-roussel]

This PR extends wazero's interpretation of rights in wasi_snapshot_preview1.path_open to allow programs to open files in either read-only, write-only, or read-write mode.

[codefromthecrypt]

Looks like how you described in slack. I'm glad this is 100pct contained to wasip1!

[achille-roussel]

Seems like I introduced a regression on wasi-testsuite, looking into it.

[achille-roussel]

So it seems we were accidentally passing one of the wasi-testsuite tests https://github.com/WebAssembly/wasi-testsuite/blob/main/tests/rust/src/bin/directory_seek.rs#L40-L44

The test validates that a directory cannot get the FD_SEEK right, since we were zeroing all bits it tricked the test into believing that we were denying seek permission on directories.

[achille-roussel]

I tuned the approach a bit to address the wasi-testsuite issue: instead of setting all bits of fs_rights_base and fs_rights_inheriting in the result of fd_fdstat_get, wazero now sets different rights depending on the file type: for directories, the rights related to file operations (e.g. read/write/seek) are removed.

[achille-roussel]

Looks like there is going to be another creative behavior to track down on windows:

--- FAIL: Test_open (0.50s)
    --- FAIL: Test_open/zig-cc (0.50s)
        --- FAIL: Test_open/zig-cc/rdonly (0.24s)
            require.go:330: expected "OK", but was "ERR: write: Success"
                D:/a/wazero/wazero/imports/wasi_snapshot_preview1/wasi_stdlib_test.go:343

[codefromthecrypt]

Probably worth splatting the comment recommendation, but either way thanks a lot for getting to the bottom of this and finding a pragmatic way out!