Redesign private key management

1. Hierarchical keys - possible implementations discussed here: https://gitlab.syncad.com/-/snippets/182
2. Clive will determine what authority roles are needed to sign a transaction. When a transaction is saved, it will automatically try to sign with any appropriate keys it has (it may only be able to partially sign the transaction). An online wallet will also store the entire "allowed signature" tree (stored as public keys) into the transaction, so that an offline wallet will have the information needed to properly sign the transaction. @bwrona said that this mechanism will be taken from CLI wallet. The details should be discussed.

Key storage and alias

1. A profile should handle a set of private keys (no duplicates allowed) which are stored in beekeeper. Private keys are stored uniquely in beekeeper.
2. Each key can have a unique alias. By default, the alias will initially be the public key associated with the private key. If a user sets the alias to null via a UI, the alias will be restored to the public key value.

authority roles

Periodically, clive will make a call to the get_account API (later to be replaced by more powerful function in lite account API) to get a list of all authority roles associated with all working accounts stored in the current profile. This key role data will then be stored into the profile. We could also have a button on the authority roles page to allow user to request an immediate update to check for changes, but probably not that important.

If the API call to fetch authority role data fails (for example if clive is offline) then the previously stored data will be left unchanged. This will allow a user to create an online wallet with no keys (i.e. they just specify their watched accounts) and fetch the roles for those accounts, then copy the profile from an online wallet to an offline wallet. This gives the user a "reasonably smart" offline wallet that knows the roles of keys (unless key permissions get changed). Probably should keep a timestamp of when the authority roles were last successfully updated.

Whenever private keys are added/removed from a profile, the mapping between authority roles and private keys should be updated to track which authority roles can currently be used for signing.

When a working account is removed from a profile: Check if any private keys associated with authority roles for the working account no longer have any other roles. If so, prompt user to see if the unused private keys should also be removed.

When a working account is added to a profile: Make a get_account API call for the account and update authority role-related data.

When a private key is removed from a profile by user: update associated authority role attachments. Or the attachments can be computed on-the-fly.

When a private key is added to a profile by a user: update associated authority role attachments. Or the attachments can be computed on-the-fly.