Fix cosmos#747

The change registers 2 gov module hooks in the provider module:

- `AfterProposalDeposit`: if the proposal is an equivocation proposal in
  voting period, then call `PutUnbondingOnHold` for each unbondings of
  each validators found in the proposal.

- `AfterProposalVotingPeriodEnded`: if the proposal is an equivocation
  proposal, then call `UnbondingCanComplete` for each unbondings of each
  validators found in the proposal.

A new key is also added, to store the equivocation proposal ID for which
unbondings have been put on hold. This covers 2 specific cases:

- The gov module allows additional deposits even if the proposal is
  already in voting period. So when `AfterProposalDeposit` is invoked,
  we have to make sure the proposal is in voting period for the first time
  before puting the unbondings on hold. This is simply handled by
  checking if the proposal ID exists in the store at the beginning of
  the hook, and then storing it if not.

- If the provider chain is upgraded with this change and there's already
  an equivocation proposal in voting period, `AfterProposalVotingPeriodEnded`
  could be invoked without the initial `AfterProposalDeposit`, so some
  unbondings could be un-paused while they hadn't been paused (conflicts with
  `AfterUnbondingInitiated` hook). To prevent that, we check the
  proposal ID exists in the store, which means `AfterProposalDeposit`
  has been called prevouisly.

Co-authored-by: Albert Le Batteux <[email protected]>