Add traits and function implementations for missing extensions

[0xMMBD]

Added implementations for missing extensions.

Traits added:

• PSP22Pausable
  • fn pause(&mut self)
  • fn unpause(&mut self)
• PSP22Wrapper
  • fn deposit_for(&mut self, account: AccountId, amount: u128)
  • fn withdraw_to(&mut self, account: AccountId, amount: u128)
• Ownable
  • fn owner(&self)
  • fn renounce_ownership(&mut self)
  • fn transfer_ownership(&mut self, new_owner: Option<AccountId>)

Traits modified:

• PSP22
  • Added fn burn_from(&mut self, account: AccountId, value: u128)
• PSP22Mintable
  • Changed mint to fn mint(&mut self, to: AccountId, value: u128)

Added error enum - OwnableError

Added function implementations for:

• burn_from
• deposit
• withdraw

Example lib.rs implementation that contains all extensions enabled can be found here: https://gist.github.com/coredumped7893/38ea06963de8c5034b58a9267be50758

Code is based on this version of the psp22: https://github.com/Smart-Beaver/smart-contracts/tree/main/PSP22

[coredumped7893]

@piotrswierzy

[h4nsu]

Hi, thanks for contribution. However, I have some doubts about this PR:

1. This repo is meant to provide a simple, minimal implementation of the standard. Traits Ownable and PSP22Pausable are not part of PSP22 standard. What is the point of adding these traits here, without implementation?
2. I don't understand PSP22Wrapper trait, it seems to be just an alias for transfer and transfer_from. What is it useful for?Also, it introduces some chain related code (cross calling) to PSP22Data, which is supposed to be an internal data structure with token logic and should stay ink-and-chain agnostic.

I like the refinement of Mintable and Burnable to mimic the interfaces known from Ethereum. Ideally burn should be removed in favor of burn_from.

[0xMMBD]

@h4nsu Regarding the second point. This is our attempt on migrating ERC20Wrapper to the ink. We wanted to keep the same functionality as openzeppelin has, so the comment from their repo gives us a summary what it does.

 * Users can deposit and withdraw "underlying tokens" and receive a matching number of "wrapped tokens". This is useful
 * in conjunction with other modules. For example, combining this wrapping mechanism with {ERC20Votes} will allow the
 * wrapping of an existing "basic" ERC-20 into a governance token.

That's why you can see some cross calling in the data.rs. Here we have E2E tests that contain comments for each step

[deuszx]

A lot of code in this function replicates fn burn - the only additional place here is the check and modification of allowances - so I'd change to code to reuse fn burn (i.e. call it and only add necessary allowances management around it).