refactor: simplify logics in FP set rotation

[SebastianElvis]

Resolves #145
Resolves #191 (fuzzed locally and it's not flaky anymore)

This PR simplifies the logics in FP set rotation, including:

• Moving event emitting to msg handlers whereever possible (mostly for jailing/unjailing).
• Removing the handling of special case len(events) == 0. This is not necessary and can be handled altogether in ProcessAllPowerDistUpdateEvents with same complexity.
• Splitting recordVotingPowerAndCache into two functions, one for recording voting power table/cache and the other for emitting events/hooks for Fp state update.
• Some minor abstraction for separating event emitting and voting power rotation algorithm.

Will do a second round of refactoring in another PR, together with #72

[gitferry]

Lgtm! @jrwbabylonlab fyi, seems we will change slashing status change to a tx event

[SebastianElvis]

fyi, seems we will change slashing status change to a tx event

Oh is having FP state change as block event mandatory for BE?

[gitferry]

Oh is having FP state change as block event mandatory for BE?

I don't think it's mandatory but let's hear from @jrwbabylonlab

[Lazar955]

lgtm

[KonradStaniec]

Oh is having FP state change as block event mandatory for BE?

Not really mandatory, but property we wanted to preserve is that one type of event - EventFinalityProviderStatusChange is always the same type. As we cannot make all status changes transaction events, we decided to make them block events.

[SebastianElvis]

Alright, for the sake of simplifying BE development I moved back the slashed/jailed FP events back, but added some helper functions for emitting these events. In addition, I tightened the interfaces exposed in power_dist_change.go. Now this file has <500 LoCs, only contains code for voting power update, and only exposes 3 public functions.