Handle contract addresses that don't implement ERC20 interface for addToken method

[0xGabi]

When we add an address with the addToken method that don't implement the ERC20 interface the Redemptions app will broke until this address is removed from the token list.

Two possible solutions are:

1. We could handle this in the frontend to prevent the app to stop working.
2. We could improve the smart contract check to prevent this kind of address to be added.

[fabriziovigevani]

From keybase:

@lkngtn :

I don’t think it’s a huge deal given the security model around adding and removing tokens. One other possible solution could be to allow users to exclude tokens when redeeming, so the redeem function cannot be blocked by an invalid token.

[yeqbfgxjiq]

While this might not be a security issue as the org can vote to add/remove tokens at will, it could be a UX issue. It should be as easy as possible for people to use our apps, esp if we're targeting open source communities who are already unfamiliar or skeptical of crypto. With that in mind, seems like encoding a check in the contract would be best since it would eliminate any potential user errors in setting up or using the app. Is there any reason not to add it as a feature to the contract other than gas fees?