Refactoring ABI encoding feature

[ahangsu]

Summary

• Removed data/abi/abi_value.go
• Encode/Decode method take golang values, the behavior should be based on ABI type schemes

closes #3027

Test Plan

• keep all the current testing methods
• modify all the previous testing involved encoding/decoding methods to accept only golang values

Minor Question

We will have to use reflection for inferring if interface{} typed value can be type-asserted to be []interface{}.

We cannot directly do a.([]interface{}), that's why reflection comes in to achieve interface{} -> []interface{}.

Any thoughts on possible work-arounds? The perf seems not penalized...

[jasonpaulos]

Looks good, just one nit

[jannotti]

To combine a couple of my points into one, maybe you should just have one TypeOf(string) function, which would replace TypeFromString(), and would be used even for getting other types. TypeOf("bool") for example. Provides a nice narrow interface. I don't know if callers need MakeUintType(int). I suspect not, and that TypeOf("uint16") etc is better, because callers will not be dynamically selecting a type programatically.

Perhaps the others would continue to exist, but not as public (capitalized) functions.

[ahangsu]

My thoughts is that, probably hide most of the Make...Type functions, and directly construct ABI-types from TypeOf.
We might want to export some of the basic type constants like: ByteType, StringType, AddressType, BoolType.

NVM, we are hiding all these type constructors for now.

[jasonpaulos]

Overall looks good, just 2 nits