Added function for locking previously delegated stake and removed requirement that delegation pool vesting start times be in the future

[isaacdoidge]

See #150 and #151.

QA Notes:

Please perform the following steps to help us verify that this new functionality is safe to deploy to and use in mainnet:

1. Start a local network running the current mainnet release (release/v7.1). Set epoch_duration_secs to something short---maybe 30 seconds. Also set recurring_lockup_duration_secs and voting_duration_secs to small values so that it is possible to unlock and withdraw stake during this test. Finally, set the genesis_timestamp_microseconds to 31 days ago (in microseconds). This will ensure that the first lockup period of the Delegation Pool vesting schedules has passed.
2. Delegate some stake to one of the genesis Delegation Pools on behalf of a few accounts using 0x1::pbo_delegation_pool::fund_delegators_with_stake. You can find the keys for the pool owners after starting the local network in smr-moonshot/remote-env/Logs/owners.
3. Move the stake of different accounts into different states:
   a. Leave one account untouched.
   b. Unlock half of the stake of one account, but do not withdraw any.
   c. Unlock the full stake of one account, but do not withdraw any.
   d. Unlock the full stake of one account and withdraw half.
4. Build the new version of the Supra Framework from dev of our fork of aptos-core and deploy it to the local network via a framework upgrade governance transaction.
5. Unlock the stake of one account just before performing Step 6. The goal of this step is to ensure that one of the accounts has a pending_inactive allocation when Step 6 is performed.
6. Lock the previously delegated stakes by calling 0x1::pbo_delegation_pool::lock_delegators_stakes. Use the original allocations when calling this function: Do not adjust for the fact that some of the stake has been withdrawn from some accounts.
7. Ensure that the remaining allocations of the accounts are now active and are subject to the vesting schedule. This can be confirmed by ensuring that the accounts that did not withdraw anything in the steps above can now unlock and withdraw their first-period allocations, and that the other accounts cannot unlock anything (yet).

[sjoshisupra]

I believe that the amount is too low for reactivation, the assertion can fail because in the pool we would have less than MIN_COIN_SHARES_IN_POOL. So (i) either we ensure that the assertion will always hold or (ii) do not perform the operation for those delegator where this might fail.