Capability Providers should Identify Themselves to Actors During Dispatch

[autodidaddict]

When a capability provider uses the dispatcher component to put a request on the message bus to be handled by an actor, the only information the actor module is given is the operation name and the payload. There are some situations where this isn't enough information:

• If an actor has bound to the same provider multiple times (e.g. using named bindings), it is entirely possible that the provider will dispatch the same operation to the actor, but for different bindings. Today the actor will have no way to differentiate those calls.
• If there are multiple providers that all have the same operation name, e.g. HandleRequest, then the actor will need to know the capability ID of the dispatching provider in order to figure out if the message was truly intended for them. (Though ideally operation names should be as unique as possible).

As a suggested mitigation for this, we should make it so that the signature for the core waSCC handler for actors include parameters for the capability ID and binding name of the dispatcher, or the actor public key in the case of an actor-to-actor invocation.

[autodidaddict]

The current Invocation structure has an origin field on it that right now only contains the capability ID of the provider that dispatched the call as seen in the dispatcher.

As we go ahead with this issue and #45 , we might want to again refactor the Invocation struct so that both the origin and target fields are of the same type, a HostedEntity enum that is just a rename of the TargetType enum. I think this will make the comms code a little easier to read.

Where this becomes a bit of a rub is that the existing wapc spec only includes the operation and the message to be invoked, and there is no parameter that lets us identify the origin or source of the invocation. Admittedly, the concept of named bindings only exists within the waSCC tier and isn't something waPC has visibility to.

So the trick, then, is how we might be able to support this feature without diluting the (what I think is) fairly pure waPC spec as it stands today. Any thoughts on this @pkedy?