Updates the README to help clarify that WASI is not W3C (#477)

There is a common confustion that WebAssembly is W3C, so WASI must also
be. However, this isn't the case and The Bytecode Alliance doesn't
describe itself in that way either. This change should help set context
so that people know what is likely to be a "real standard" vs a valuable
part of the greater WebAssembly ecosystem.

Signed-off-by: Adrian Cole <adrian@tetrate.io>

README.md

@@ -41,9 +41,34 @@ wondering how to do something more realistic, like read a file. WebAssembly
 Modules (Wasm) are sandboxed similar to containers. They can't read anything
 on your machine unless you explicitly allow it.
 
-System access is defined by an emerging specification called WebAssembly
+The WebAssembly Core Specification is a standard, governed by W3C process, but
-System Interface ([WASI](https://github.com/WebAssembly/WASI)). WASI defines
+it has no scope to specify how system resources like files are accessed.
-how WebAssembly programs interact with the host embedding them.
+Instead, WebAssembly defines "host functions" and the signatures they can use.
+In wazero, "host functions" are written in Go, and let you do anything
+including access files. The main constraint is that WebAssembly only allows
+numeric types.
+
+For example, you can grant WebAssembly code access to your console by exporting
+a function written in Go. The below function can be imported into standard
+WebAssembly as the module "env" and the function name "log_i32".
+```go
+env, err := r.NewModuleBuilder("env").
+	ExportFunction("log_i32", func(v uint32) {
+		fmt.Println("log_i32 >>", v)
+	}).
+	Instantiate()
+if err != nil {
+	log.Fatal(err)
+}
+defer env.Close()
+```
+
+While not a standards body like W3C, there is another dominant community in the
+WebAssembly ecosystem: [The Bytecode Alliance](https://github.com/bytecodealliance/governance).
+The Bytecode Alliance controls the WebAssembly System Interface ([WASI](https://github.com/WebAssembly/WASI)),
+which is a set of function imports similar to Go's [x/sys/unix](https://pkg.go.dev/golang.org/x/sys/unix).
+The "wasi_snapshot_preview1" version of WASI is widely implemented, so wazero
+bundles an implementation. That way, you don't have to write these functions.
 
 For example, here's how you can allow WebAssembly modules to read
 "/work/home/a.txt" as "/a.txt" or "./a.txt":
@@ -57,6 +82,10 @@ defer module.Close()
 ...
 ```
 
+While we hope this deeper dive was useful, we also provide [examples](examples)
+to elaborate each point. Please try these before raising usage questions as
+they may answer them for you!
+
 ## Runtime
 
 There are two runtime configurations supported in wazero, where _JIT_ is default:
@@ -121,16 +150,38 @@ This approach ensures compatibility with any parent image.
 
 ## Standards Compliance
 
+wazero understands that while no-one desired to create confusion, confusion
+exists both in what is a standard and what in practice is in fact a standard
+feature. To help with this, we created some guidance both on the status quo
+of WebAssembly portability and what we support.
+
 The [WebAssembly Core Specification 1.0 (20191205)](https://www.w3.org/TR/2019/REC-wasm-core-1-20191205)
 is the only part of the WebAssembly ecosystem that is a W3C recommendation.
 
 In practice, this specification is not enough. Most compilers that target Wasm
-rely both on features that are not yet W3C recommendations, such as
+rely on features that have not yet gone through W3C recommendation process,
-`bulk-memory-operations` and the [WebAssembly System Interface (WASI)](https://github.com/WebAssembly/WASI),
+such as `bulk-memory-operations`.
-whose stable point was a snapshot released at the end of 2020. The aim of this
+
-section is to familiarize you with what wazero complies with, and through that
+Also, most compilers implement system calls using the WebAssembly System
-understand the current state of interop that considers both standards (W3C
+Interface ([WASI](https://github.com/WebAssembly/WASI)). While WASI aims to be
-recommendations) and non-standard features your tooling may use.
+a common layer for portability, it is not governed by a standards body, like
+W3C. Moreover, while commonly implemented, WASI is not yet versioned. Its last
+stable point was the "wasi_snapshot_preview1" tag released at the end of 2020.
+
+While this seems scary, the confusion caused by non-standard features and
+non-standard specifications is not as bad as it sounds. The WebAssembly
+ecosystem is generally responsive regardless of where things are written down
+and wazero provides tools, such as built-in support for WASI, to reduce pain.
+
+The goal of this section isn't to promote a W3C recommendation exclusive
+approach, rather to help you understand common language around portable
+features and which of those wazero supports at the moment. While we consider
+features formalized through W3C recommendation status mandatory, we actively
+pursue non-standard features as well interop with commonly used infrastructure
+such as AssemblyScript.
+
+In summary, we hope this section can guide you in terms of what wazero supports
+as well as how to classify a request for a feature we don't yet support.
 
 ### WebAssembly Core
 wazero supports the only WebAssembly specification which has reached W3C