Providing a wasip1 stat API on top of wasip2 is infeasible

[whitequark]

In short, the problem is that it is difficult or impossible to implement a wasi preview1 adapter that consumes the wasip2 API (metadataHash and isSameObject) and provides the wasip1 API (st_dev/st_ino). Right now the adapter is using the lower word of metadataHash for st_ino, but this has two issues:

1. Implementing metadataHash to always return 0 is legal in wasip2, but this causes applications to conclude that all files they read are actually the same file, and breaks e.g. Clang.
2. Implementing metadataHash to return something that can be the same for two different files that are not hard links to each other (e.g. hash of file contents) causes applications to conclude that these unrelated files are actually the same file, and breaks e.g. tar which will create an archive with a hard link where none exists on the filesystem.

See the prior discussion in bytecodealliance/wasmtime#8956.