Study spearbit changes for possible regression issues about v1-core HOT 1 CLOSED

• #290 - this adds safety checks to our initializer. The new behavior of the contract after this change is that if maxSupply/_convertibleRatio/_collateralRatio are too high - then the createBond method will fail. Reverting at the createBond step is good.
• #282 naming change - no possible regression issues.
• #288 - This breaks convert and redeem for non-owners. Fixed with #292, additionally we have decided not to accept this suggestion
• #262 - This upgrades the OZ contracts and adds an internal function call to the implementation contract constructor to prevent it from being initialized. This change should be investigated further for regression. I looked through the OZ upgrade from 4.5->4.6 and didn't seem to be any changes except to Initializable. Additionally I studied the _disabledInitializes method and no possible side affects that I could think of. This method is in the constructor, so it had zero affect on the proxy contracts, only affects the implementation contract
• #283 this removes a zero assignment from collateralTokensRequired. Solidity docs explicitly say that [The default value fro the uint types is 0] (https://docs.soliditylang.org/en/latest/control-structures.html#default-value)
• #285 this does not change any smart contract behavior - it only changes the value that is emitted from the pay method. However, it's weird that it's calling balanceOf manually instead of using our paymentBalance() method #296
• #287 - This is changing the behavior in sweep which could potentially add issues when trying to sweep tokens. It adds an additional check, that uses the previous logic for calculating sweepingTokenBalance to check if there are actually tokens to transfer. I investigated if we have tests making sure that we have an example where . Overall as well - this is a lower-risk method for us as it exists purely as a utility incase of transfer mistakes or airdrops. Unexpected reverts in this method would not affect the proper functioning of our contracts, it would only prevent sweeping of tokens sent to the contract by mistake. @RusseII to investigate this method further and think of ways that a malicious actor may be able to sweep tokens from the address when they are not supposed to. Created #301

from v1-core.