Issue receipts for aggregator - cron stack

[vasco-santos]

Thoughts that might be important for this #48 (comment)

In current implementation we are adding aggregate/add right on the exit of the first queue that is wired with aggregate/queue. This gives us the control of the flow, as well as to guarantee that no further same piece can be added.

However, by executing aggregate/add at that point, receipt chain will not enable storefront to get to know aggregate + inclusion proof. Probably worth to perform the aggregate/add when we include things into an aggregate that is ready to be sent. With that in mind, we would wire the aggregate-add queue when we queue the deal (in dealer-queue workflow). The disadvantage is not being able to re-act fast for multiple piece adds, which given we control the storefront now is not really a problem. However, if we would have direct users of the aggregation pipeline (like what we talked with FVM team), opening this door could be an issue.

An alternative here would be to introduce a third capability aggregate/inclusion, where aggregate/add is executed as in this PR, and the above solution would be the aggregate/inclusion (where of course we would add effect from aggregate/add to aggregate/inclusion.