Fix (most) incorrect reports of custom errors

[haltman-at]

Partially addresses #5881. This is not a total fix, but it fixes the bulk of the problem.

Let's suppose you send a transaction, and it fails due to OOG, or, say, never even happens in the first place (like, intrinsic gas too low, or refused by the user in MetaMask). In this case, the eth_call to determine the revert reason can succeed and get a return value instead of the intended error. Since we can't decode it as an error, we treat it as a custom error. Oops!

This PR fixes this by checking the length; if it's 4 mod 32, we treat it as an error, if it's not, we don't. Assuming the Solidity ABI is being used, then error responses will have length 4 mod 32 (unless they're empty), while return value responses will have length 0 mod 32.

(Well, except for when we're dealing with contract creations, in which case successful responses can have any length, but, uh, I'm just going to not worry about that...)

This is arguably not a total fix for two reasons. Firstly, there's the case of contract creations as mentioned above; in that case we could still hit the bug if the length of the returned contract just happends to be 4 mod 32. Secondly, what if the transaction never happens -- e.g. it was refused by the user in MetaMask -- but the subsequent eth_call reverts with a valid error? In this case, we'll append a revert string where it doesn't make sense, and it will be confusing for the user.

In order to address these cases, we should probably go, like, actually checking error codes and such. However, that would take some actual research, and I thought I should at least start by putting up this quick fix that handles the most frequent cases. We can do a more comprehensive fix later.

Testing instructions

I added two tests in contract-tests to test this PR. You might also want to see the original issue if you want to test it manually.

[cds-amal]

Looks good. I tested this with a too-little-gas tx and it behaved as predicted.

[haltman-at]

Note: I was thinking of going back and changing this to have the 4-mod-32 check also apply to Error strings, but the chances of that ever being relevant are so low, because it would have to (very nearly) be a correctly-formatted string otherwise... we can change that on returning to this if we really care. :P