Allow pro-rated rewards to be claimed without ending the validation.

[cam-schultz]

Context and scope
Currently, validator rewards are claimable only after the validation is ended. This requires validators to end a validation, ending all delegations to it, in order to claim any rewards. This is poor UX for both validators (who want to attract delegators) and delegators (who often want to set and forget).

Instead, we should allow validators to supply an uptime proof at any time to claim the appropriate rewards, without ending the validation.

Discussion and alternatives
One way to accomplish this would be to track the claimableRewards by address, and provide a method submitUptimeProof that updates and releases the claimable rewards based on the received uptime reletive to the validation start time and the current block timestamp. Once #489 is complete, it's likely the same function can be called here as in completeEndValidation to compute and release the rewards.

Open questions
Should this feature be implemented for delegators? The UX considerations are less severe, since there are no other parties affected.

[cam-schultz]

We need to decide how this will interact with uptime based rewards. I think the soundest approach would be to treat each pro-rated rewards collection as starting a new virtual validation period. The existing validation period would remain intact, but we would additionally track all values needed to calculate the uptime based rewards for the current virtual validation period. Each virtual validation period would be independent.

We'd have to separately track the uptime of previous validation intervals to calculate the uptime for subsequent intervals. The uptime rewards check would look something like: (uptimeSeconds-lastClaimUptimeSeconds+lastClaimTime)/(currentClaimTime - lastClaimTime) < UPTIME_REWARDS_THRESHOLD_PERCENTAGE/100. The denominator shifts the calculation to the current validation interval defined by the numerator. We'd then set lastClaimUptimeSeconds to uptimeSeconds and set lastClaimTime to currentClaimTime.

To avoid further complicating the arithmetic, I think we should revert if the pro-rated claim uses an uptime that's not eligible for rewards. There's no real use case to doing otherwise.