feat(fc-pallet-pass): handle provisioning of system accounts for session keys

[pandres95]

To reduce the usability friction in pallet-pass we created the concept of Sessions, which are analogous to pure proxy controllers, for which an arbitrary account, represented by a public key (i.e. the session key), previously attached to a pass Account is allowed to execute calls on behalf of such account.

This implies that to correctly pass the transaction validity step before a session key account can dispatch a call on behalf of the Pass Account, the account needs to exist in the system (a.k.a. be provisioned).

This Pull Request resolves this by handling the provider references such account needs in a manner that works both for accounts that already exist in the chain as well as accounts that do not yet exist.

Related to #27: Should we be using signed origins as session keys in the future? Or should we find a way to extend the validity of some pass credentials over time, in such a way we handle these future validations via the pass Account only?

[jgutierrezre]

lgtm

[olanod]

Let's use the scheduler to auto remove sessions based on their expiration block and extend the removal schedule when necessary.

Side note based on our talk, in a different PR let's improve our account generation in account_id_for which currently trusts user provided data when it shouldn't. I propose something like

// we know the length of HashedUserId
let mut input = [0u8; TWICE_THE_LEN_OF_HASHED_USER_ID];
input[..HASHED_USER_ID_LEN] = input.copy_from_slice(&user);
let account = hash_input_and_magically_convert_to_account(&input);

[olanod]

LGTM :)