Introduce strongly-typed system primitives (#1561)

* Introduce strongly-typed system primitives

This commit does a lot of reshuffling and even some more. It introduces
strongly-typed system primitives which are: `OsFile`, `OsDir`, `Stdio`,
and `OsOther`. Those primitives are separate structs now, each implementing
a subset of `Handle` methods, rather than all being an enumeration of some
supertype such as `OsHandle`. To summarise the structs:

* `OsFile` represents a regular file, and implements fd-ops
  of `Handle` trait
* `OsDir` represents a directory, and primarily implements path-ops, plus
  `readdir` and some common fd-ops such as `fdstat`, etc.
* `Stdio` represents a stdio handle, and implements a subset of fd-ops
  such as `fdstat` _and_ `read_` and `write_vectored` calls
* `OsOther` currently represents anything else and implements a set similar
  to that implemented by `Stdio`

This commit is effectively an experiment and an excercise into better
understanding what's going on for each OS resource/type under-the-hood.
It's meant to give us some intuition in order to move on with the idea
of having strongly-typed handles in WASI both in the syscall impl as well
as at the libc level.

Some more minor changes include making `OsHandle` represent an OS-specific
wrapper for a raw OS handle (Unix fd or Windows handle). Also, since `OsDir`
is tricky across OSes, we also have a supertype of `OsHandle` called
`OsDirHandle` which may store a `DIR*` stream pointer (mainly BSD). Last but not
least, the `Filetype` and `Rights` are now computed when the resource is created,
rather than every time we call `Handle::get_file_type` and `Handle::get_rights`.
Finally, in order to facilitate the latter, I've converted `EntryRights` into
`HandleRights` and pushed them into each `Handle` implementor.

* Do not adjust rights on Stdio

* Clean up testing for TTY and escaping writes

* Implement AsFile for dyn Handle

This cleans up a lot of repeating boilerplate code todo with
dynamic dispatch.

* Delegate definition of OsDir to OS-specific modules

Delegates defining `OsDir` struct to OS-specific modules (BSD, Linux,
Emscripten, Windows). This way, `OsDir` can safely re-use `OsHandle`
for raw OS handle storage, and can store some aux data such as an
initialized stream ptr in case of BSD. As a result, we can safely
get rid of `OsDirHandle` which IMHO was causing unnecessary noise and
overcomplicating the design. On the other hand, delegating definition
of `OsDir` to OS-specific modules isn't super clean in and of itself
either. Perhaps there's a better way of handling this?

* Check if filetype of OS handle matches WASI filetype when creating

It seems prudent to check if the passed in `File` instance is of
type matching that of the requested WASI filetype. In other words,
we'd like to avoid situations where `OsFile` is created from a
pipe.

* Make AsFile fallible

Return `EBADF` in `AsFile` in case a `Handle` cannot be made into
a `std::fs::File`.

* Remove unnecessary as_file conversion

* Remove unnecessary check for TTY for Stdio handle type

* Fix incorrect stdio ctors on Unix

* Split Stdio into three separate types: Stdin, Stdout, Stderr

* Rename PendingEntry::File to PendingEntry::OsHandle to avoid confusion

* Rename OsHandle to RawOsHandle

Also, since `RawOsHandle` on *nix doesn't need interior mutability
wrt the inner raw file descriptor, we can safely swap the `RawFd`
for `File` instance.

* Add docs explaining what OsOther is

* Allow for stdio to be non-character-device (e.g., piped)

* Return error on bad preopen rather than panic

crates/wasi-common/src/sys/windows/fd.rs

@@ -1,7 +1,9 @@
 use super::file_serial_no;
-use super::oshandle::OsFile;
+use super::oshandle::RawOsHandle;
 use crate::path;
-use crate::sys::oshandle::AsFile;
+use crate::sys::osdir::OsDir;
+use crate::sys::osfile::OsFile;
+use crate::sys::AsFile;
 use crate::wasi::{types, Result};
 use log::trace;
 use std::convert::TryInto;
@@ -39,7 +41,10 @@ pub(crate) fn fdstat_get(file: &File) -> Result<types::Fdflags> {
 // handle came from `CreateFile`, but the Rust's libstd will use `GetStdHandle`
 // rather than `CreateFile`. Relevant discussion can be found in:
 // https://github.com/rust-lang/rust/issues/40490
-pub(crate) fn fdstat_set_flags(file: &File, fdflags: types::Fdflags) -> Result<Option<OsFile>> {
+pub(crate) fn fdstat_set_flags(
+    file: &File,
+    fdflags: types::Fdflags,
+) -> Result<Option<RawOsHandle>> {
     let handle = file.as_raw_handle();
     let access_mode = winx::file::query_access_information(handle)?;
     let new_access_mode = file_access_mode_from_fdflags(
@@ -49,7 +54,7 @@ pub(crate) fn fdstat_set_flags(file: &File, fdflags: types::Fdflags) -> Result<O
             | access_mode.contains(AccessMode::FILE_APPEND_DATA),
     );
     unsafe {
-        Ok(Some(OsFile::from_raw_handle(winx::file::reopen_file(
+        Ok(Some(RawOsHandle::from_raw_handle(winx::file::reopen_file(
             handle,
             new_access_mode,
             fdflags.into(),
@@ -120,13 +125,13 @@ fn file_access_mode_from_fdflags(fdflags: types::Fdflags, read: bool, write: boo
 // ..       gets cookie = 2
 // other entries, in order they were returned by FindNextFileW get subsequent integers as their cookies
 pub(crate) fn readdir(
-    file: &OsFile,
+    dirfd: &OsDir,
     cookie: types::Dircookie,
 ) -> Result<Box<dyn Iterator<Item = Result<(types::Dirent, String)>>>> {
     use winx::file::get_file_path;
 
     let cookie = cookie.try_into()?;
-    let path = get_file_path(&file.as_file())?;
+    let path = get_file_path(&*dirfd.as_file()?)?;
     // std::fs::ReadDir doesn't return . and .., so we need to emulate it
     let path = Path::new(&path);
     // The directory /.. is the same as / on Unix (at least on ext4), so emulate this behavior too