Providing a wasip1 stat API on top of wasip2 is infeasible

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.

Start with the wasip1 stat API and the wasip2 metadataHash and isSameObject entry points described in the issue. Read the linked prior discussion in bytecodealliance/wasmtime#8956, then evaluate whether a mapping can avoid false file identity for cases such as Clang and tar. Done should establish a viable approach or clearly document why the API cannot be provided safely.