[V110-specific] Avoid handler_solvency redundant SetMimirs and EventSetMimir emissions

[V110-specific]

This MR does not seek to change how final Mimir key values at the end of a block,
but seeks to prevent an insolvency-set Mimir key changing back-and-forth several times within a single block.

As an example: block 9916655, in which there were five "set_mimir" emitted events as Mimir key SolvencyHaltGAIAChain changed in the below pattern:
0->9916655->0->9916655->0->9916655.

This also produced unintuitive noise in #mainstream-info in Discord.

[AUTO] Mimir Value: SOLVENCYHALTGAIACHAIN has CHANGED from 0 -> 9916655
[AUTO] Mimir Value: SOLVENCYHALTGAIACHAIN has CHANGED from 0 -> 0
[AUTO] Mimir Value: SOLVENCYHALTGAIACHAIN has CHANGED from 0 -> 9916655
[AUTO] Mimir Value: SOLVENCYHALTGAIACHAIN has CHANGED from 0 -> 0
[AUTO] Mimir Value: SOLVENCYHALTGAIACHAIN has CHANGED from 0 -> 9916655

It is my intention that with this MR's changed code that block would have only had a single 0->9916655 and single "set_mimir" event.

At most, I predict only two automatic set_mimir events (and KVStore key value cahnges) could take place in the same block for a given SolvencyHalt key,
in the form of high->0->higher (if a solvent vault unhalted the chain and then the insolvent vault rehalted it).

An solvent vault can unhalt a chain by the end of the block (relying on the insolvent vault to rehalt it in a later block),
but that is the same for current code.
(An alternative would be for an insolvent vault to update the SolvencyHalt value even if it were already greater than zero.)

I also note that if solvency messages are only broadcast upon perceived insolvency then I do not see how automatic unhalting of a chain can take place (whether upon NOOP restoration of solvency or updated information that a vault is solvent after all).

More of my thought process is present in this Discord thread.