Return multiple signatures from transaction authenticator

Currently, the `TransactionAuthenticator` provides a way to get only a single signature for a given message (via the `get_signature()` method). However, in some scenarios, we may want to get multiple signatures for the same message.

Consider the example of an account which is a multisig with 2 users signers + PSM (private state manager). Assuming there is a signature from the user, the PSM could generate signatures "automatically". The flow could work like so:

1. The user executes a transaction and requests a signature from the authenticator.
2. The authenticator (via the wallet interface) prompts the user to sign the relevant transaction summary.
3. At the same time, the authenticator sends the transaction summary to the PSM and gets the signature from it.
4. The authenticator returns both the user's signature and the PSM's signature to the kernel.
5. The kernel is now able to complete the transaction.

There is no easy way to support such a flow easily. To support this, we need to answer two questions:

- How does the authenticator know that for a given transaction it needs to reach out to the PSM?
- How does the authenticator return multiple signatures to the kernel?

On approach to answer these questions could be introduce something like `get_signatures()` method. It could look like so:

```rust
pub trait TransactionAuthenticator {
fn get_signatures(
&self,
pub_keys: &[PublicKeyCommitment],
signing_inputs: &SigningInputs,
) -> impl FutureMaybeSend, AuthenticationError>>;
}
```
Importantly, this method could return fewer signatures than the specified public keys, and would fail only if no signatures could be generated.

Then, in the above scenario, the auth procedure could request signatures for all signers, and would receive two signatures back (one for the user key and the other for the PSM key), which would be sufficient to proceed with the transaction.

The main question is what triggers this method. My initial thinking is that we'd need to add something like `MultiAuthRequest` (or maybe `AuthRequestMulti`) event. This event would be similar to our current `AuthRequest` event - but instead of reading `PUB_KEY` from the stack, it would read a list of public keys from a memory location.

The stack for state expected by this event could be:
```
[event_id, MESSAGE, pub_key_ptr, num_pub_keys]
```