feat(*): Adds initial config interface implementation

[thomastaylor312]

This is the most basic functionality needed to have a shared config interface that all components could use. It's goal is simplicity. There are many things we could add/polish, and all of those are called out in the documentation. For reference, this is what we are using in wasmCloud, but we aren't married to the interface as is. What we want is the ability for any runtime to be able to provide configuration to the components it is running in a standardized way. That will make it possible to actually have the cross runtime/platform experience that components promise

[thomastaylor312]

Please note that I'll be intermittently available the rest of the week and completely unavailable next week, so if I don't respond, that is why!

[thomastaylor312]

Great question @lann! So there are definitely some distinct differences between KV and config. But more importantly, the ultimate goal here are interfaces that increase interoperability. This is the absolute bare minimum interface that heads towards that goal and allows a component to indicate very clearly that "I am looking for config" rather than a datastore. Some additional points:

• Having to do config via a KV means you have to have a KV store available. Some platforms and use cases might not have that immediately available. It also leads to an awkward experience: "To configure your component, write the following keys to Redis before running it."
• Related to the last point, but there is a difference between a data store and configuration. Yes, config may possibly be derived from a remote database or tool like vault, but more often than not it is also combined with host specific things, for example what k8s passes to pods by default. There is also a reason why things like ConfigMaps and external config exists for K8s and Nomad. You could theoretically have people store stuff directly in etcd/consul and access that, but config is something that most applications need.
• With those last points in mind, it is also important to note that this is meant to be the least common denominator for interoperability. Not everything is going to use wasi:cli/environment with environment variables (but it could be easily virtualized out with a component that converts from env vars to config values). wasmCloud is obviously my easiest example here, but any system that is running untrusted code or not as a FaaS type system could either not expose or have other security reasons for not wanting to expose environment variables to the system, instead delegating that layer of control to the host.

[thomastaylor312]

Hey all (particularly @Mossaka and @devigned)! Now that we're in the new year, I'd like to circle back to this and see if we can get it approved or have a concrete list of things to change. Please let me know your thoughts!