Add ARC0020 - token standard allowing public/private transfer to contracts

[r001]

Let's list the token standard proposals so far:

1. PULL#14 (README.md, main.aleo, discussion) has listed the required instructions for token standard that allows contracts to interact with tokens publicly:
   They are: balance_of, total_supply, approve, transfer_from, transfer, and allowance.
   ARC20 includes 3 optional rules. They are: decimals, name, symbol.
   Advantages:

   1. Provides methods for public contract interaction.
      Disadvantages:
   2. Had to use very old snarkVM features.

   Thanks to @EdVerally for his contribution.

2. PULL#34 (README.md, (main.aleo - in README.md), discussion) created a unique standard by using records even for public transfers.
   Advantages:

   1. It also allows for upgradability.
   2. It allows to handle unlimited tokens with one single codebase, which is an advantage of this method (with HarukaMa's concerns)

   Disadvantages:

   1. Does not provide solution for sending tokens to contracts.
   2. Credential concept is strange.

   Thanks to ghostant-1017 for this unique addition.

3. PULL#41 (README.md, main.aleo, discussion)
   Advantages:

   1. Has a solution for public contract usage.
   2. Clear and usable.

   Disadvantages:

   1. Applies the (discussion) approve() transition, instead of offline signatures, which is both more awkward, uses more system resources at each calling of approve(), and the codebase is also around 41 lines longer than that of offline signatures.

   Thanks for the Aleo team to come up with this solution.

None of the above concepts address the processing of private tokens by smart contracts.

4. Current ARC0020 here. (README.md, main.aleo, discussion)
   Advantages:

   1. Provides offline signature solution for public tokens to be used by contracts.
   2. Provides solution for private tokens to be used by contracts.
   3. Provides simple solution to make sure contract is indeed belonging to the company website.

   Disadvantages:

   1. No solution for total_supply.
   2. Does not create one single contract for all tokens (would save storage space).
   3. Current implementation of ZERO_ADDRESS is awkward a bit.

[zklim]

The offline signing approval method is currently vulnerable to replay attack as the struct hash is not constrained enough to include information like network.id, function id, program id and nonce etc.

[zklim]

The current hash only takes to, from, amount and expiry into account. The to address can use this signature to drain amount many times from from address as long it has balance and not expired.

Not to mention the to address can replay this signature on other tokens on the same / other network that implemented the exact same signature scheme.