Add better redemption mechanics

[adamdossa]

Redemption Mechanics:

NB - redemption / burning is the same thing - currently we use burn rather than redeem as the verb.

Currently we have a burn function that references a ITokenBurner contract that can only be called by the user wishing to burn tokens.

Issues:

• No ability to approve someone to burn tokens on your behalf
• no way for issuer to burn tokens (forceTransfer doesn’t allow transfer to 0x0 or reducing the totalSupply)
• no way for a module to burn tokens
• not possible to have multiple burn mechanics

Requirements:

• Token holders cannot directly burn tokens - must happen through a REDEMPTION type module
• REDEMPTION type modules cannot arbitrarily burn tokens, users must approve the module first for the amount of tokens that they are ceding control over
• Issuer can force burn tokens (reducing total supply) subject to the same controls as forceTransfer

Implementation:

• Addition of burnFrom as an analogue of transferFrom - i.e. uses allowance to burn tokens on behalf of someone else
• burn and burnFrom can only be called from a REDEMPTION type module
• Addition of forceBurn to allow an issuer to burn someone elses tokens (subject to same controls as forceTransfer
• Issuer cannot call burn or burnFrom (i.e. we use onlyModule, not onlyModuleOrOwner)
• Remove tokenBurner as redemption logic will instead happen in REDEMPTION module
• Renamed STO_KEY as MINT_KEY and added BURN_KEY as a module type

Notes:

• One type of behaviour this doesn’t allow is forced burning via a REDEMPTION module. However the issuer can still force burn tokens.

[satyamakgec]

Looks good to me @pabloruiz55 please take a second look