This makes several updates to the messaging interface. Initially the
README said that this wasn't going to support request/reply, but based
on my reading of the Kafka, NATS, MQTT, and SQS APIs, this is a fairly
common pattern. Another piece of evidence here is what I've seen as a
wasmCloud maintainer from our users. Request/reply is one of the more
common things we see with a messaging service. Please note that this
doesn't _require_ the use of a reply-to topic, just exposes it for use.

I also did a few other changes here. First is that I added the topic to
the message. This was common across all systems and is often used by code
to select the appropriate logic to perform. I also removed the format
field as this didn't seem to be a common parameter across various services.
We could definitely add a content-type member to this record in the future
if needed, but I think much of that can be passed via the metadata field.

There are other things I might suggest some changes to, but I want to think
on them some more and open some issues to discuss them first

Signed-off-by: Taylor Thomas <taylor@cosmonic.com>

This PR integrates various changes from talking to current users of
messaging in the community as well as conversations among the champions

Signed-off-by: Taylor Thomas <taylor@cosmonic.com>

I also deleted the examples.md for now until we settle on the interface.
It will be easier to add back in once we have some real world examples
to point at

Signed-off-by: Taylor Thomas <taylor@cosmonic.com>

Also removes extensions as a guest configuration option (for now)

Signed-off-by: Taylor Thomas <taylor@cosmonic.com>

In many of the interfaces out there right now, we've moved more towards
just calling these things config

Signed-off-by: Taylor Thomas <taylor@cosmonic.com>

Also removes the channel parameter I forgot to remove in a previous
commit

Signed-off-by: Taylor Thomas <taylor@cosmonic.com>

…ions

One of the uses of request-multi is to support a scatter/gather operation.
In these cases, you might not know how many requests you are going to
receive, so you can't set expected replies. Generally these wait until
timeout and then return the results. This commit adds the ability to
support all the different use cases for request-multi

Signed-off-by: Taylor Thomas <taylor@cosmonic.com>

After a whole bunch of feedback from the community, I realized we were
still trying to make this interface too much. So I dramatically paired
back the interface to be purely focused on message passing. Further
features like ack/nack, guaranteed delivery, and so on are now out of
scope (see the README for full details).

This was partly inspired by a discussion in the CNCF Wasm WG around this
interface. To be perfectly frank, the level I paired this down to is
essentially the same level of guarantees offered by the wasmCloud
[messaging interface](https://github.com/wasmCloud/messaging). The main
reason being is that there are people actually using that interface for
real applications (with real host implementations). If we can come to
agreement on a simpler interface, it will be easier to add in functionality
such as the things I stripped out in this commit.

Please let me know any feedback you have around this, focusing on whether
or not this covers at least the most basic scenarios

Signed-off-by: Taylor Thomas <taylor@cosmonic.com>

…d nits

Signed-off-by: danbugs <danilochiarlone@gmail.com>

Signed-off-by: danbugs <danilochiarlone@gmail.com>

Signed-off-by: danbugs <danilochiarlone@gmail.com>

Signed-off-by: danbugs <danilochiarlone@gmail.com>

…metadata method, added new-line at the end of files, improved argument names, removed .gitignore, improved documentation, changed get-subscriptions function name

Signed-off-by: danbugs <danilochiarlone@gmail.com>