JSON ABI types vs. Type string types

### What was wrong?

The initial version of eth-abi was designed to accomodate basic types (types of the form `<sub>` such as `int256[2]`, `fixed128x18` etc.</sub>

Later, support was added for tuples by extending eth-abi to handle type strings such as `(int,int)`, `(bool,(fixed,int))[]` etc.

However, the problem with this approach is that most interaction with the ABI encoding format is done via information obtained from a JSON ABI specification for a contract. The JSON ABI represents tuple types entirely differently like the following:
```
{
"type": "tuple",
...
"components": [
{"type": "int", ...}, {"type": "int", ...}
]
}
```

More information about the JSON ABI format can be found here: https://solidity.readthedocs.io/en/latest/abi-spec.html#json

Because of this, a number of utility functions were added to convert JSON ABI type information to type string representations. But this seems like a potentially unnecessary step. Ideally, we shouldn't have to use type strings as a kind of intermediate type format.

### How can it be fixed?

One possible fix for this could be to convert or extend eth-abi to detect appropriate coders for a type based on a JSON ABI type description (instead of a type string). So a type registry could receive a dict object representing a JSON ABI type and produce the correct coder.

I'm not sure how hard this would be or if there are any problems with that approach that I'm not considering. But I wanted to make a note of it here in case we choose to take a look at it later.