fix: `setFees` reverts if underlying's LT is below any of collaterals' LTs, accounting for ramps

[lekhovitsky]

Fixes:

• https://github.com/spearbit-audits/review-gearbox/issues/59
• https://github.com/spearbit-audits/review-gearbox/issues/104

[StErMi]

@lekhovitsky with the current implementation you are now considering both the "current" LT of a token (taking in consideration the possible ramp) and the final LT (when the ramp ends or if there's no ramp) when the underlying LT must be updated.

If there are ramps in actions, but you want to set the LT of the underlying to zero, it would always revert. What's your plan in this case? Set each token's LT to 0 without any ramp, and then setting the underlying LT to 0?

[StErMi]

If there aren't already, I think that this would be a good time to add some test cases where you try to

• update underlying's LT to 0, but there are ongoing ramping down/up LT for other tokens → this should revert
• underlying LT > 0, other tokens have ramping → set token's LT to zero + set underlying's LT to 0 → this should revert
• other tests that prove the general invariant: token's current OR final LT must always be <= ltUnderlying

[lekhovitsky]

@StErMi With 100% certainty we won't set underlying's LT to 0 so we don't even consider this case in our analysis and tests.

[lekhovitsky]

The final test does make sense, although invariant tests for configurator actions reasonably have slightly lower priority compared to user actions. We do have relatively exhaustive integration tests for these edge cases though.