SecretStore: versioned keys

[svyatonik]

Changes:

1. instead of rewriting share (this could lead to share loss as described in TODO3 from SecretStore: administrative sessions prototypes #6605 ), ShareAdd session would append new version to existing key
2. before decryption/signing session can start, we must choose version we want to use in this session => new KeyVersionNegotiationSession
3. ShareRemove && ShareMove are obsoleted && removed, since we do not want to lose and change any key share versions
4. I have no plans to make an API for starting ShareAdd session right now, because this change have removed its main use case. So it will be used only as nested session in ServersSetChange session
5. changed ShareAdd implementation so now it works even if some owners of key shares are offline/removed. Thought it would be an easy task, but spent several days working on it && had to switch the paper, this session is based on.
6. ServersSetChange session now uses KeyVersionNegotiationSession + ShareAdd session to add shares to all new nodes && after completion just clears databases of nodes, that are removed from cluster

This PR fixes most of #6605 TODOs (except for 1 && 5.1).

Behind the scenes: initial idea (#6605 (comment)) was built on assumption that node is static, when is isolated from cluster. But this isn't true in general - we can make cluster1, then split it to cluster2 + cluster3 && then merge back to cluster4. So failed ShareAdd session is not the only reason of different key versions. And there's no easy way to protect key shares from tree-like versioning (had some exotic ideas of how to achieve this, though) . So let's just live with it (I felt depressed before accepting this fact).

[svyatonik]

Latest commit have fixed the test for me, but looks like now there are some ci problems.