Fix encoding of fixed-size arrays

[blitz-1306]

When implementing #42, we figured that ABI-encoding of inline arrays is not properly working for following cases:

• https://github.com/Consensys/sol2maruir/blob/7dc4449395a0fc0b077f7b4864ba1141ec2e1b42/test/samples/solidity/EncodingTest.config.sol#L21
• https://github.com/Consensys/sol2maruir/blob/7dc4449395a0fc0b077f7b4864ba1141ec2e1b42/test/samples/solidity/HashingTest_v0424.config.sol#L17
• https://github.com/Consensys/sol2maruir/blob/7dc4449395a0fc0b077f7b4864ba1141ec2e1b42/test/samples/solidity/HashingTest_v0424.config.sol#L32

Inline array type strings are computed to a tuples. This is done by solc-typed-ast here: https://github.com/Consensys/solc-typed-ast/blob/68aa8cacfef4e3de66764a136258d8fbf5c6e559/src/types/infer.ts#L2418-L2432. For those tuples web3's encodePacked() resulting empty byte array. We better clarify why type inference produce this, as it seems to be intentional.

Literals with type strings are emitted by CFGBuilder.getAbiTypeStringConst() and used in ExpressionCompiler.prepEncodeArgs().

[cd1m0]

Originally we decided to convert fixed array types to tuples in toABIEncodedType due to this paragraph in the docs on abi encoding:

"
T[k] for any T and k:

enc(X) = enc((X[0], ..., X[k-1]))

i.e. it is encoded as if it were a tuple with k elements of the same type.
"

However looking at the compiler output for fixed arrays, especially the function hashes, it seems that the canonical representation is still the array one. Given this sample:

contract Foo {
    function foo(int8[3] memory a) public {}
}

The function hash looks like this:

{
    "a8ee3160": "foo(int8[3])"
}

So perhaps we have to fix this in solc-typed-ast? This would likely require a major release in solc-typed-ast and fixes to scribble and sol-dbg

[blitz-1306]

Here is a pull request to solc-typed-ast, that fixes ABI type string: ConsenSysDiligence/solc-typed-ast#223

It does not produce any regression in Scribble, solc-typed-ast, sol-dbg local tests against this branch...

Still, something interesting happends with following sample in Remix IDE:

pragma solidity 0.4.24;

contract HashingTest {
    function usesKeccak256() public returns (bytes memory, bytes32) {
        return (abi.encodePacked([int8(1), 2, 3]), keccak256([int8(1), 2, 3]));
    }
}

Calling usesKeccak256() produces following:

0x000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000003
0x6e0c627900b24bd432fe7b1f713f1b0744091a646a9fe4a65a18dfed21f2949c

The packed encoding, that is currently provided by IR, produces 0x010203 (therefore, hash is different). I guess that when we encode arrays, it should use full slots anyway, but it "shortens" slots to uint8.

[blitz-1306]

So it is getting even weirder. I would like to deliver this fix to solc-typed-ast anyway, as it does not seem to cause any harm to dependent packages. In IR package we still need to figure out how to handle it properly.