This commit switches the wasi target to loading CLI arguments via the
syscalls provided by wasi rather than through the argc/argv passed to
the main function. While serving the same purpose it's hoped that using
syscalls will make us a bit more portable (less reliance from libstd on
an external C library) as well as avoiding the need for a lock!

I've since learned that the mapping between libc fds and wasi fds are
expected to be one-to-one, so we can use the raw syscalls for writing to
stdout/stderr and reading from stdin! This should help ensure that we
don't depend on a C library too unnecessarily.

This routes the `error_string` API to `strerror` in libc which should
have more human readable descriptions.

This commit fills out the `std::fs` module and implementation for WASI.
Not all APIs are implemented, such as permissions-related ones and
`canonicalize`, but all others APIs have been implemented and very
lightly tested so far. We'll eventually want to run a more exhaustive
test suite!

For now the highlights of this commit are:

* The `std::fs::File` type is now backed by `WasiFd`, a raw WASI file
  descriptor.
* All APIs in `std::fs` (except permissions/canonicalize) have
  implementations for the WASI target.
* A suite of unstable extension traits were added to
  `std::os::wasi::fs`. These traits expose the raw filesystem
  functionality of WASI, namely `*at` syscalls (opening a file relative
  to an already opened one, for example). Additionally metadata only
  available on wasi is exposed through these traits.

Perhaps one of the most notable parts is the implementation of
path-taking APIs. WASI actually has no fundamental API that just takes a
path, but rather everything is relative to a previously opened file
descriptor. To allow existing APIs to work (that only take a path) WASI
has a few syscalls to learn about "pre opened" file descriptors by the
runtime. We use these to build a map of existing directory names to file
descriptors, and then when using a path we try to anchor it at an
already-opened file.

This support is very rudimentary though and is intended to be shared
with C since it's likely to be so tricky. For now though the C library
doesn't expose quite an API for us to use, so we implement it for now
and will swap it out as soon as one is available.