RToken Ethereum Contracts

As it presently is constructed, the contract is vulnerable to the [allowance double-spend exploit](https://github.com/OpenZeppelin/openzeppelin-solidity/blob/b4f87bb8fc25fb07f73099701e39e167a3d36465/contracts/token/ERC20/ERC20.sol#L71-L78), as with other ERC20 tokens.

While the code prevents from the obvious inheritance case where the recipient is the original owner (`SELF_HAT_ID`) on `L478`, it seems that the `src` can hand craft a hat that makes him-/her-self a recipient. This way it would be automatically inherited by the recipient.

Every Solidity file specifies in the header a version number of the format `pragma solidity (^)0.5.*`. The caret (`^`) before the version number implies an unlocked pragma, meaning that the compiler will use the specified version _and above_, hence the term "unlocked." For consistency and to prevent unexpected behavior in the future, it is recommended to remove the caret to lock the file onto a specific Solidity version. Because the use of `ABIEncoderV2`, the `pragma` should be locked above `0.5.10`, as there is a known bug in array storage: [https://blog.ethereum.org/2019/06/25/solidity-storage-array-bugs/](https://blog.ethereum.org/2019/06/25/solidity-storage-array-bugs/) There are currently no signed integer arrays that are initialized in a vulnerable way, hence the low severity of this issue. However, it is best to take precautions for future updates of the code.

In the functions `distributeLoans` and `recollectLoans` a user may accidentally lock oneself out if the number of `recipients` or the number of `proportions` is too high. Consequently, the for loops on lines 612, 619, 697 and 793 will require too much gas to finish and the transaction (function call) will fail for those accounts.