Extract confirmation height to its own database

[wezrule]

While logically connected to an account_info the confirmation height is updated separately in a different thread. This means a lock is required when using something like RocksDB because there can be write conflicts when writing to the same account. As account_put is only called as part of the block_processor thread and confirmation height for existing accounts is done in the confirmation height processor thread (and new accounts in the block processor thread) no external synchronization should be required if they are separated. This won't help with lmdb yet because it uses a single global write lock, it would require it to be moved to a completely separate store file. This wasn't done (as moving it to a new database was painful enough), but this would help with other backends which don't use a global write lock (e.g rocksdb) and also enable it to be moved to a new lmdb store more easily if required.

It's very important to keep the accounts in accounts_v0/_v1 in sync with the confirmation_height database. There is a debug assert in account_put which has a precondition that the account exists in the confirmation_height database. No such check exists in account_del because it may just be removing from accounts_v0 to put in accounts_v1 and so makes sense to keep the confirmation_height entry and not impose a precondition there.