Storage API

A filesystem API as the only means to retain state in an application can be quite limiting, specially if the host platform doesn't have the concept of a filesystem, this can result in a bunch of glue code in the host to emulate a file system and for applications that have simple storage needs it also means bundling more code to adapt to the filesystem interface.

Since WASI isn't supposed to stay as a low level POSIX-like collection of interfaces but also encourages the definition of higher level APIs that can serve specific(but still widely used) use cases, I think a simple storage API can be a great addition.
So how should said API look like? 🤷🏽 That's up for discussion! but here are some ideas and I'll be thrilled to hear some more thoughts ...

• Async. Not sure what's the current status of async calls in WASI but I think this one should be async from the start.
• Simplicity. We want to be high level but not too much to force people into a specific kind of design pattern like an object store or relational DB. Simple Key Value storage of plain bytes should be a good start?
• Isolation. If it's not obvious, like the file system, WASM modules shouldn't be able to access other module's storage.
• Namespaces. Or the lack of it? instead of being able to create and open different DBs perhaps a module just gets a default namespace that is already "open", the user anyway already showed her intention of using the storage by enabling that capability. - - Prefixes. To aid in lack of name spacing, we can make it easy to retrieve keys which follow a common prefix.
• Transactional. I think a simple transactional system can still fit in the design of this simple API. It's my understanding that something like a callback is possible which the host can use to revert changes if it returns an error code or something.

No implementation files, tests, or entry points are named. Start by reviewing the issue's proposed async, byte-oriented key-value, isolation, namespace, prefix, and transaction requirements, then determine whether the community has agreed on an API design; done means a decided specification with an identified implementation path.