Consider adding failure reason information to MessageExecutionFailed event

[cam-schultz]

Context and scope
When a message fails to be executed in a call to receiveCrossChainMessage, the contract emits MessageExecutionFailed. It does not, however include any information as to why execution failed. The reasons for failure are numerous, but would generally be due to logical or format errors in the encoded calldata, or insufficient gas allocated in the Teleporter message.

Discussion and alternatives
We should consider adding the failure reason to MessageExecutionFailed

Open questions
We need to determine what the best way to encode a general failure reason in the log.

[michaelkaplan13]

One difficultly in trying to propagate failure information into a log event is that it requires allowing the contracts being called to return arbitrary data to Teleporter. This allows the contract being called to spend more gas outside of the call since that data is then handled by the Teleporter contract. (similar to #107)

In order to disallow the contract called from spending arbitrary gas, I think we would need to limit the amount of data they can return in the event of failure in assembly, effectively truncating the failure reason.

Also, only AFAIK, only failure messages due to require(false, message) statements will be included in the return data. Other errors such as trying to call a contract/function that doesn't exist won't have descriptive messages either way.

I'm currently thinking that handling that returned data within assembly and spending more gas in any event is not worth the benefit of having the certain failure reasons included in logs.