feat: add wasi-0.3.0 draft

[rvolosatovs]

Refs https://github.com/orgs/bytecodealliance/projects/16/views/1?pane=issue&itemId=88153596
Refs WebAssembly/wasi-sockets#111
Refs #156 (change sets seem to be complimentary)

Followed the example of wasi-http and wasi-clocks duplicating the package in a subdirectory

This vendors wasi-clocks from WebAssembly/wasi-clocks#77

• Remove would-block error code
• Replace wasi:io/error.error usage by error-context
• Replace wasi:io/streams.input-stream return values by stream<u8> in return position
• Replace wasi:io/streams.output-stream return values by stream<u8> in parameter position - Guests should be able to rely on stream.new to construct streams
• Merge read{,via-stream} into a singular read. Both functions take an offset as a parameter and since they now return stream<u8>, callers can limit the amount of bytes read by using the stream<u8> directly, therefore functionality of both is identical
• Merge write{,via-stream} into a singular write. Both functions take an offset and stream<u8> as a parameter.

It is assumed that error-context returned by writes to the stream and reads from the stream are sufficient for error handling.

See also

• https://www.man7.org/linux/man-pages/man2/write.2.html
• https://www.man7.org/linux/man-pages/man2/pwrite.2.html
• https://www.man7.org/linux/man-pages/man2/read.2.html
• https://www.man7.org/linux/man-pages/man2/pread.2.html

[rvolosatovs]

Same as in WebAssembly/wasi-sockets#111 (comment), removed the error-context introspection in a separate commit (which can be dropped if desired)

[sunfishcode]

Thanks for putting this together! Overall this looks good.

One additional thing we should look into is translating directory-entry-stream into stream<directory-entry>.

Similar to this discussion in wasi-sockets, what would you think about renaming read/write/append back to read-via-stream/write-via-stream/append-via-stream in order to make room for a future read/write that uses newer language features when they become available?

    read: func(
        /// The offset within the file at which to start reading.
        offset: filesize,
    ) -> result<tuple<stream<u8>, future<option<error-code>>>, error-code>;

Could we simplify this interface by eliminating the outer result and error-code here? The way this function works, any implementation is likely going to need to maintain its own cursor, so this function itself doesn't need to do any I/O. It currently does fail if the stream is not readable, but perhaps we could instead have implementations return a closed stream and report it in the future<option<error-code>> instead.