WASI: Greater isolation between fd and file functions

[npmccallum]

In one particular implementation of a WASM runtime (not yet public), we plan to support file descriptors but not a filesystem. It would be great if filesystem related functions could be a separate specification.

It would also generally be good to create a stronger separation between operations which work on file descriptors in general and those which work only on files in a filesystem. The precedent for this already exists in the __wasi_sock_*() functions.

[sunfishcode]

Some preliminary thoughts here:

The API does use a naming scheme; __wasi_fd_* functions just operate on file descriptors, while __wasi_path_* operate on paths, so it's pretty easy to distinguish between them.

That said, the capability model doesn't depend on absolute paths at the syscall level, so there's no requirement for a traditional-looking filesystem (C:\ or /etc or anything else). In fact, it doesn't even need to be an actual filesystem; it's just a hierarchical namespace of resources, which could be entirely virtual, like Linux's /proc.

[npmccallum]

I have (not yet public) reasons for wanting these calls in a separate module. See #74 for my preferred approach.

[sunfishcode]

Ok. FWIW, others have requested we split out the command-line argument and environment variable handling into separate modules too. I think these are reasonable, but it does feel like something we should do once we have a proper forum, such as a CG Subgroup, which we'll hopefully have soon.

[npmccallum]

I've requested an invite to the meeting. Hopefully, we'll be collaborating more directly in a short time.

[sunfishcode]

The modularization PR has now landed, so this will be in the next snapshot!