Consider adding better custom Debug implemenatations for messages

[hashedone]

Some messages (eg. WasmMsg::Execute) contains Binary field being actually a json message passed to something. Technically speaking this is chunk of bytes, practically speaking - it is [almost] always a json. After all, on test using MT I get a result like:

thread 'multitest::total_credit_line::lender_on_three_markets' panicked at 'called `Result::unwrap()` on an `Err` value: error executing WasmMsg:
sender: lender
Execute { contract_addr: "Contract #2", msg: Binary(7b226465706f736974223a7b7d7d), funds: [Coin { denom: "OSMO", amount: Uint128(1000) }] }

Caused by:
    0: error executing WasmMsg:
       sender: Contract #2
       Execute { contract_addr: "Contract #3", msg: Binary(7b226d696e74223a7b22726563697069656e74223a226c656e646572222c22616d6f756e74223a2231303030227d7d), funds: [] }
    1: Cannot process zero tokens', contracts/isotonic-credit-agency/src/multitest/total_credit_line.rs:99:10

And obviously having an actuall message here would be very helpful. Creating custom debug impl which prints this binary as string would be probably easier to work with.

[ethanfrey]

This is a follow up from #1199 (note this Debug is better than before)

Simon objected to making assumptions that this is a readable string. (And sometimes, this is raw bytes, like u64 big endian encoded). Happy to revisit, but please read the discussion on the linked issue

[webmaster128]

When we have the Binary embedded in some context, I think it is fair to optimize for the expected content as long as the general case is supported as a fallback. I.e. I would not change the Debug implementation of Binary but the Debug implementation of WasmMsg::Execute.msg.

[ethanfrey]

I would not change the Debug implementation of Binary but the Debug implementation of WasmMsg::Execute.msg.

Oh, that is a very nice idea. Cuz we can be quite sure that in this case it will be raw json. (Enforced by wasmd)