Create ABI parser module

I want to add more type safety to the Contract call by adding type parameters to call and invoke (related: https://github.com/apibara/starknet-react/issues/98).

The first issue I noticed is that the encoder/decoder for cairo types is coupled with the Contract class, which for example forces tests to make a contract call to test the encoding/decoding. I propose to create a new encoding module with the following functions:

// from typescript types to felt arrays
function encodeInputs<A>(args: A, method: string, abi: Abi): string[];
function encodeFelt(arg: string | number): string[];
function encodeStruct<A extends object>(arg: A, abi: Abi): string[];
function encodeTuple<A extends unknown[]>(arg: A, abi: Abi): string[];
function encodeArary<A>(arg: A[], abi: Abi): string[];

// from felt array to typescript
function decodeOutputs<R>(data: string[], method: 'string', abi: Abi): R;
function decodeFelt(data: string[]): string; // seems useless
function decodeStruct<R extends object>(data: string[], abi: Abi): R;
function decodeTuple<R extends unknown[]>(data: string[], abi: Abi): R; 
function decodeArray<R>(data: string[], abi: Abi): R[];

A couple of notes:

• encodeInputs must accept either an array of arguments (technically a tuple) or an object to be backward compatible with how call parses inputs at the moment
• decodeOutputs is more tricky because the current implementation returns an object that’s both an array and an object.

Related: can add a { strict: true } option to throw an error if any struct/tuple has more arguments than required (#140).

After this issue is fixed adding type checking to call and invoke should be relatively easy.

[ivpavici]

For now it is a simple POC, it works for an ERC20 contract… But a lot is missing, you are free to suggest!

[ivpavici]

@cwkang1998 feel free to contribute to https://github.com/ivpavici/abi-wan-kanabi 😃