Enforce state transitions and incentivize calls

[NicholasDotSol]

State transitions from one deposit state to another require someone calling the corresponding transition method on the deposit and actually spend gas on it. This issue assumes that participants are not always pushing forward through the state machine as soon as a new state becomes available, opening up the possibility of having multiple state transitions being a valid option for a deposit.

Ensure that there are no competing interests between participants of the system to favor one transition over the other, causing race conditions, front-running opportunities or stale deposits that are not pushed to end-states.

issues to fix:

• A TDT holder can choose not to call out notifySignerSetupFailure hoping that the signing group still forms after the signer setup timeout passes.

• The deposit can be pushed to active state even after notifySignerSetupFailure, notifyFundingTimeout have passed but nobody called it out. -> If both parties want to let the deposit activate later, that's their prerogative.

• Members of the signing group might decide to call notifyFraudFundingTimeout in a race to avoid late submissions for provideFraudBTCFundingProof to succeed in order to contain funds lost due to fraud. -> provideFraudBTCFundingProof is no longer a state.

• A malicious signing group observes BTC funding on the bitcoin chain in an attempt to commit fraud at the time the provideBTCFundingProof transition becomes available to front-run provideFundingECDSAFraudProof forcing the deposit into active state.

• If oracle price slippage occurs for one block (flash-crash type of event) someone could call an undercollateralization transition.

• A deposit term expiration courtesy call can be exit in the rare case where _d.fundedAt + TBTCConstants.getDepositTerm() == block.timestamp

[Shadowfiend]

@NicholasDotSol do you mind linking the PRs that have fixed the fixed issues?

[Shadowfiend]

Closing this as we've handled all the ones that were a problem.