Fire callback & add to history after confirmation height is set

[wezrule]

After a block has won an election, the roots are removed but the blocks/dependents are not removed until confirmation height is now set, same with dependent elections.

Moved existing confirmation height tests to their own file, as they are getting quite large (1000+ lines). Added 2 new tests which check that the callback/confirmation history is set correctly for inactive/quorum and dependent elections observer stats.

Added pause/unpause functionality to the confirmation height processor, so that I can more easily prevent it confirming any blocks until desired.

Should be used in conjunction with #2156 to be completely consistent.

Note for reviewers:
Consider the following situation, a simple chain with 2 un-cemented send blocks:
1 - The frontier is being confirmed with an active election, it gets added to the conf height processor and then iterates over both blocks and it about to write the confirmation height of the account to include both blocks.
2 - block_confirm is called on the dependent block and is not marked as confirmed yet so an election is started.
3 - The confirmation height processor in the first step now sets the confirmation height on the frontier and the dependent block, callbacks and confirmation history are updated for both blocks.
4 - Election in 2 finishes, what should happen?

In master this will fire off the callback and add to the confirmation history due to the finished election, but now we only want to do this after setting the confirmation height. The confirmation height for the block is already set and will only fire a duplicate callback in json_handler::block_confirm if the block is confirmed at that point in time. Is this an issue? Should the confirmation height processor detect the already confirmed block and if from a confirmed election always fire the callback as well? (for consistent duplicates at least?).

[cryptocode]

Recent idempotency clarifications in https://docs.nano.org/integration-guides/block-confirmation-tracking/ should make the possible dupes mentioned in the description acceptable. As long as there is no risk of lost observer calls (to trigger websocket notifications), this LGTM. No need to trigger to get duplicates for consistency's sake IMO.