Add confirmation height

[wezrule]

These are summarized notes given before the start of this work:

When we confirm a block what we want to set the account's confirmation height to be equal to the height of the block just confirmed. So if the confirmation height was 2 and the block height is 7, we set the confirmation height to 7. For each block that was implicitly confirmed; 7-3, we check if it’s a receive block. If it’s a receive block we update the confirmation height of the sender in the same fashion. The algorithm needs to be iterative, not recursive since this could be a deep confirmation process. When we update the database, all confirmation heights start as zero and when the first confirmed block comes off the live network it’s going to confirm a ton of accounts.

The sideband upgrade has been made synchronous (approved by @clemahieu) to make the process simpler for future upgrades. This means nodes will be very slow to start if going from v17.1 -> v19 however the big services/exchanges should have been made aware of this during the v18 release announcement so it should not affect many nodes.

New RPC block_confirmed has been added to check if a block has been confirmed and the account_info has been modified to output the confirmation height of an account as well. MSVC only compiles up to 128 if/elseif blocks (well 128 nested blocks) which was reached after I added 2 RPC calls. I have combined the password/payment RPC calls into another one temporarily until a better solution can be found. A possible solution is to use a std::map<std::string, std::function<void(rpc_handler*)>> which maps action => handler for functions with no arguments.

--snapshot now accepts an optional confirmation_height_clear option for clearing the confirmation heights (setting to 0) for all accounts.
--confirmation_height_clear CLI option can also be used directly as well, with an optional account for clearing single account.

Updated nano/core_test/versioning.cpp to have tests for all account_info_v* classes

lmdb.cpp - nano::mdb_store::account_get() didn't check the error condition from info_a.deserialize (stream); and same in pending_get(), so I have added those.

There are still some questions around pending blocks, but this can always be done in a separate PR.

[argakiig]

Formatting and LGTM

[SergiySW]

LGTM (squash)

[wezrule]

Stein has ran it for 12 hours and found most blocks spend < 1ms inside the iterative function add_confirmation_heights with a few outliers when there are long chains but they don't lock long enough to cause rpc lockups. Merging this in now so that any problems can be found sooner. Zach has some further questions about functionality but these can be investigated separately as this is a building block for further enhancements.