Provide a way to get results from messages

[ethanfrey]

We use a "fire-and-forget" actor model for dispatching messages. This has some large security benefits and avoids a few classes of bugs from ethereum, notably re-entrancy attacks, which are very tricky to defend against. However, sometime we do want a return value from a function - like when we create an object with an auto-incremented ID and want to save that ID in the caller.

There is one solution to this, which we can see when using IBC. The rough flow is:

• Caller commits an intermediate state (eg locks to-be-sent coins in an escrow)
• Caller dispatches IBC message
• Sometime later, the receiving chain processes the message and returns a Result
• Even later, the original contract gets an "ibc_ack" with an identifier of the original message and the result of execution. It can use that to look up the intermediate state and commit it or roll it back.

This does run over multiple transactions and multiple chains. We could simplify this somewhat to allow callbacks in the same TX:

• Caller makes updates and dispatches a message, message contains callback: Option<HumanAddr>.
• Callee processes tx, then dispatches a custom response message to the contract address listed in callback if set
• Original contract gets the callback info and somehow knows what to update.

How we handle identifiers and callbacks needs plenty of specification, but I think that rough flow could work if both sides are designed for it. We need to finalize a design for the low-level api and add some helpers to make this easier to work with.

[webmaster128]

Superseded by #691 and done