VAL-129 [Refactor] Switch to per-lender "crank" that iterates over snapshots

[ams9198]

The diff looks huge, but the vast majority of that is tweaking existing tests and adding new ones.

Per convo on Slack, this is a refactor (actually simplification) of the Pool "snapshot" and the per-lender mechanism for "claiming" their portion of the snapshotted funds. Instead of a direct computation using aggregated values, this iterates over the interim snapshots from the time a lender requested and accumulates shares / assets according to each snapshot "redeemableRate" and "fxRate". The global snapshot is still constant-time and run lazily on mutating events (as before).

There are two new functions exposed to the Pool/WithdrawController (very open to feedback on naming and the signatures of these):

claimSnapshots(uint256 limit) --> iterates of "n == limit" snapshots to "catch up" the lender. This updates the lender's withdrawState -- moving eligibleShares over to redeemableShares according to each snapshot.
needsClaim() view returns bool --> signals whether a lender is "caught up" or not.

The semantics change slightly, as there's less lazy magic as before. A simple pseudo code scenario to explain:

// Period 1. LenderA requests withdrawal
pool.requestRedeem(1000)

// Period 2, 3, etc. 
// pool gets cranked lazily on any mutating function (this is still constant-time).

// Period n 
maxWithdrawal() == 0 // lenderA hasn't "claimed" funds from the snapshots yet 

pool.claimSnapshots(100); // now they're up-to-date
maxWithdrawal() == 1000

Basically, a lender will now explicitly need to claimSnapshots before their redeemableAssets get allocated. This seems simpler to reason about -- money moves explicitly, and things like maxRedeem() simply read from the state vs. doing an invisible computation.

This fixes the specific audit issue, and also eliminates some of the "dust" quirks of the direction computation approach.

[venables]

This looks correct to me!