Optimize votes lookups for recent checkpoints

[frangio]

This PR optimizes getPastVotes so that for recent checkpoints it has lower gas cost than the worst case.

The worst case runs in O(log n) time, but delegates can have large numbers of checkpoints: a quick search led us to find one with 8500 checkpoints, which adds around 43k gas to a vote.

In the context of governance, since there is a voting period, getPastVotes will be invoked with a relatively recent block which will be near the end of the checkpoints array.

We modify getPastVotes so that it first checks to see if the sought checkpoint is a recent checkpoint, if so does a binary search among those, and otherwise does a binary search on the rest of the array. We define the recent checkpoints as the last sqrt(n), where n is the number of checkpoints. Thus, the best case cost of getPastVotes is half that of the worst case, though it remains logarithmic.

---

Some other changes bundled here:

• Changed ERC20Votes to use unsafe array accesses to save on bounds checks.
• Renamed getAtRecentBlock to getAtProbablyRecentBlock, to indicate that the function works even for non-recent blocks.
• Removed upperLookupRecent for other Trace/Checkpoints types, since we won't be using it and if the keys are not block numbers or timestamps it is not clear that they are worth it.

[Amxx]

In the provided graph, we can see the transition from the "lookup is recent and cheap" to "lookup is older and more expensive" when the offset reaches 7. Yes you say K=16. Do you have an explanation for that ? I would expect the transition to appen around K

[frangio]

I think I may have been mistaken and the chart was for K=8.

I've now modified the PR to use K=sqrt(N).

[Amxx]

Code looks good, but wee need better coverrage.

[frangio]

Added tests and coverage is good now.