Port useful abi utility methods to public utils directory

[fselmo]

We have many handy abi utility methods that live under the web3._utils.abi directory that could be made stable / public via our public utilities directory in web3.utils.abi. Something that comes to mind is a method like encode_method_call(fn_signature, params), for example.

Some of these could make more sense if they lived in eth-abi (maybe eth-utils makes more sense as mentioned below) and could be exposed through web3.py if desired, sort of like how the eth-utils methods to_hex(), to_bytes(), etc, are passed through via Web3.to_bytes()...

This seems like a low-hanging fruit since that logic exists internally in the web3.py library. Making it public and massaging it into methods that are easy to understand and use could go a long way.

[reedsa]

I'm curious if we also want to consider moving abi functions that reside in eth-utils. They seem to be closely related to other abi functions, so keeping everything in one place (probably eth-abi) would be ideal.

Another option, which may not make sense, is to move all things to eth-utils and just deprecate eth-abi entirely. I'm not sure what value one has over the other to be honest. My guess is everything "utility" would be easiest to find under the eth-utils package. Just food for thought.

[fselmo]

deprecate eth-abi entirely.

eth-abi houses the implementation for ABI encoding & decoding. I think it's a reasonable abstraction to leave that to its own library / repository.

I wouldn't be against using eth_utils a bit more for "public" utils though if it makes sense to - even if we end up exposing it via web3.py where / if necessary. The distinction of what should live in eth-utils vs web3.utils is one that would be good to think about. If the answer is "everything" then we can just port useful fxns over to eth_utils and call that the public utilities.

[reedsa]

In #1596 we decided most functions which deal with a contract's ABI belong closer to its context within Web3. We started releasing event and function helpers publicly via web3.contract.utils.

When other functions are exposed, consider whether it is a generalized util and might fit best in eth-utils or if an ABI is involved it may belong in web3.contract.utils.