Decide on dangling symlink semantics under Windows

Windows distinguishes between file symlinks and directory symlinks. It's possible to create a dangling symlink, but the type (file/directory) has to be specified upfront, upon creation.

The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created `foo -> bar` and later, a directory `bar` is created. Then:
* under msys64 bash, `cd foo` succeeds and the directory view is the same when access either directly or through the symlink
* under cmd (both windowed and as a child process from msys64 bash). `cd foo` fails with `The directory name is invalid`
* under Windows Explorer, the dangling symlink is invisible

We should decide how WASI should handle a request to create a dangling symlink. Possible ideas:
1. default to file symlinks, make sure that WASI can correctly handle them even in case of type mismatch and neglect the fact that they may be broken outside WASI
2. as in 1., but correct the symlinks when encountered/upon close/etc.
3. deny creating dangling symlinks altogether and modify the tests to disallow it (it may break existing code! so probably a bad idea)

cc @kubkon @sunfishcode @peterhuene