Allow new time-unlocked deposits into periodic vesting accounts

[JimLarson]

What is the Problem Being Solved?

We need to be able to combine monthly vesting (in the true sense - transfer of tokens changing their ownership) and lockup: making tokens usable but not transferrable.

Lockup is implemented by "vesting accounts". Currently, the locked-up tokens are deposited at creation time and there is a fixed schedule for unlocking the tokens which cannot be modified.

Doing vesting plus lockup with the current vesting accounts would require creation of a new account each month.

Instead, we'd like to be able to add new deposits with their own unlocking schedule to an existing vesting account.

Description of the Design

An account with multiple concurrent unlockings looks like a PeriodicVestingAccount - it subsumes the other types (except for a ContinuousVestingAccount, which we don't use).

We'd like a new message type (with associated tools) to add a new deposit with its own unlocking schedule to an existing account. Like the message to create a vesting account, it should transfer the tokens as part of execution. Alternatively, we could reuse the "create" message but merge instead of fail when the account already exists.

The existing machinery should handle the interaction with staking, etc.

We might be able to use the vestcalc command as-is, having it produce only the schedule for the new deposit. Logic internal to x/auth would need to merge the schedules.

This will necessarily be a modification to cosmos-sdk, probably with no changes to agoric-sdk.

Security Considerations

Signatures required would be similar to those needed for creating a new account.

Test Plan

Need to check the various permutations of merging.

[JimLarson]

Per a conversation with @michaelfig today, decided to reuse the existing command (which creates a new account) with a --merge flag, which will require the account to already exist as a periodic vesting account, then merge the schedules and transfer the new donation.

[JimLarson]

See agoric-labs/cosmos-sdk#136

[JimLarson]

Was leaving open to track upstreaming, but that's now covered by #4455, so closing this.