Support migrating C Tor keystores to Arti

We need to design and implement an arti hss ctor-migrate subcommand for migrating C Tor hidden services to Arti.

Open questions:

1. Should this tool do a "hard" migration by default (i.e. should it delete the C Tor keys at the end of the migration), or should it leave the old keys behind? This is a tradeoff between security and usability: not having the key material duplicated across multiple places is better for security, but worse for usability, as users won't easily be able to switch back to using C Tor. On the other hand, if we add a flag (or a new subcommand) for reversing the migration (by converting the Arti keystore back to a C Tor one), deleting the keys by default might not be so bad. We need to decide:

   • what the default behavior should be, and
   • whether we want to support reverse migrations

2. What will this subcommand look like? One option is arti hss ctor-migrate --config <ARTI_CONFIG> --nickname <HS_NICK> --from <CTOR_KEYSTORE_ID> [--to <TARGET_KEYSTORE_ID>] (where CTOR_KEYSTORE_ID is the keystore ID of the C Tor keystore to migrate, as configured in the <ARTI_CONFIG>, under the [storage.keystore.ctor.services.<HS_NICK>] section)

3. Do we want a spcialized KeyMgr API for the migration (KeyMgr::migrate(to, from)), or are we going to use the existing APIs (by manually insert()ing the keys)? What will the tor-keymgr (or tor-key-forge) APIs for converting keys to C Tor format look like?

4. What should happen if the Arti keystore already contains keys for the service being migrated? Do we prompt to overwrite, or abort, requiring a --force flag to be passed? (I think we should go with the latter)

cc @hjrgrn, @rhatto, @wesleyac