make an observability interface

[danbugs]

We don't have an interface that allows observability like Dapr does, but we definitely need one. This task will involve the design of an interface, the implementation of a host that exports it, an example that imports it, and testing.

[Mossaka]

https://github.com/open-telemetry/opentelemetry-rust/blob/main/examples/async/src/main.rs

[danbugs]

after our discussion today regarding the Dapr alignment, we've decided to:

• chat with the Dapr folks,
• add a "compare and contrast" section to the README to show parallels between SpiderLightning and Dapr,
• create a containerd shim for slight for further Dapr comparisons (i.e., in multi-node environments) — this, perhaps, will shed some light on the service invocation building block,
• defer #101 subtask: re-think and unify mq and pubsub interfaces #119 at least until after the discussion with the Dapr folks,
• defer #101 subtask: make an observability interface #106 at least until after we have a solid implementation of the HTTP crate (no point observing 1ms runs),
• defer #101 subtask: re-name kv.wit to a more general name #120, and, consequently, abandon #101 subtask: rename kv to a more general name #121 at least until after we talk to the Dapr folks,
• considering, previously, I removed the issues regarding to blob and sql creation, maybe bring them back after we talk to the Dapr folks and learn about their experience w/ people's usage of their state management building block, and
• leave lockd as is for now~ although not one of Dapr's building blocks, they have a component for it: https://docs.dapr.io/reference/api/distributed_lock_api/.

cc: @devigned, and @Mossaka

closing as per above (from #101)

[danbugs]

bringing this back as now we have an implementation of the HTTP capability

[danbugs]

~need to create a WASI proposal.