[wasi-common]: yanix now returns io::Error directly (#1242)

* Yanix now returns io::Error

This commit may seem somewhat controversial at first, but hear me
out first. Currently, Yanix would return a custom error that's a
wrapper around three other error types returned by various entities
inside Rust's `libstd`. In particular, Yanix's error type would wrap
`io::Error`, `num::TryFromIntError` and `ffi::NulError`. It turns
out that there is a natural conversion between the first and the last
and provided by the standard library, i.e., `From<ffi::NulError> for io::Error`
is provided. So at the surface it may seem that only the first two
wrapped error types are worth keeping.

Digging a little bit deeper into `libstd`, `num::TryFromIntError`
is essentially speaking only a marker that the integral conversion
went wrong. The struct implementing this error stores a unit type,
and nothing more. It therefore seems like a waste to wrap this
particular error when we could unify everything under `io::Error`.
And so, whenever we perform an int conversion, I suggest we simply
remap the error to `io::Error::from_raw_os_error(libc::EOVERFLOW)`
since this carries a comparable amount of information.

As a result of completely discarding `yanix::Error` custom error type,
we are invariably simplifying `yanix` itself, but also allowing
`wasi-common` to simplify in several places as well.

* Adapt wasi-common to changes in yanix

* Add Cargo.lock

* Unwrap try_into's where possible

* Remove unnecessary type annotation

crates/wasi-common/yanix/src/sys/emscripten/mod.rs

@@ -5,12 +5,20 @@ pub(crate) mod fadvise;
 #[path = "../linux/file.rs"]
 pub(crate) mod file;
 
-use crate::{dir::SeekLoc, Result};
+use crate::dir::SeekLoc;
 use std::convert::TryInto;
+use std::io::{Error, Result};
 
 impl SeekLoc {
     pub unsafe fn from_raw(loc: i64) -> Result<Self> {
-        let loc = loc.try_into()?;
+        // The cookie (or `loc`) is an opaque value, and applications aren't supposed to do
+        // arithmetic on them or pick their own values or have any awareness of the numeric
+        // range of the values. They're just supposed to pass back in the values that we
+        // give them. And any value we give them will be convertable back to `long`,
+        // because that's the type the OS gives them to us in. So return an `EINVAL`.
+        let loc = loc
+            .try_into()
+            .map_err(|_| Error::from_raw_os_error(libc::EINVAL))?;
         Ok(Self(loc))
     }
 }