Directory listings should include preopens

Transferred from https://github.com/bytecodealliance/wasmtime/issues/6396

wasi-libc's behavior (and hence Wasmtime's behavior) for directory listings (via the WASI fd_readdir API?) is surprising and is inconsistent with Wasmer.

If there is a preopen for /blah, do you expect a directory listing for / to include /blah? Most people would do, because that's how all normal filesystems work. However:

• This is not the case with wasi-libc/wasmtime. Each directory listing returns only the files that literally exist on the host within that directory, ignoring any other preopens that may be mapped into the guest directory.
• But it is the case with wasmer - it correctly includes other preopens that have been mapped to the guest directory.

Repro code: https://gist.github.com/SteveSandersonMS/ff5f5cb91524bbcde24a168841e66f10

Existing application code could be broken in strange ways if typical filesystem invariants are not maintained (e.g., "a directory's parent always contains that directory").

After discussion at https://github.com/bytecodealliance/wasmtime/issues/6396 with @bjorn3, it sounds like:

• The ability to even see preopened directories as existing within a global file hierarchy (as opposed to being more like independent file hierarchies) is a feature of wasi-libc intended for compatibility with existing code
• For compatibility, then, it makes sense to complete this picture and also simulate the existence of ancestor directories containing the preopens. For example, simulating that a preopen exists at /a/b/c entails also simulating that /a/b exists and contains c, etc, otherwise filesystem invariants are broken.

Start with the linked fd_readdir behavior and the reproduction gist, then review the discussion from the transferred issue. The change is done when directory listings expose preopened directories and their simulated ancestor directories consistently with the stated filesystem invariants.