Rework wrapper signature workflow

[grarco]

We define in the SDK SigningTxData, which is a support type to sign transactions, as follows:

namada/crates/sdk/src/signing.rs

Lines 65 to 76 in 7ac415a

	pub struct SigningTxData {
	/// The address owning the transaction
	pub owner: Option<Address>,
	/// The public keys associated to an account
	pub public_keys: Vec<common::PublicKey>,
	/// The threshold associated to an account
	pub threshold: u8,
	/// The public keys to index map associated to an account
	pub account_public_keys_map: Option<AccountPublicKeysMap>,
	/// The public keys of the fee payer
	pub fee_payer: common::PublicKey,
	}

After #3883 and #3900 it seems like the fee_payer field is too limited. We don't always want to sign the wrapper transaction or sometimes we might have an offline signature that we'd want to use instead of producing a new one. This seems to lead to some workarounds in the codebase to allow these different workflows: we should think about reworking this piece of data to support these cases (no signature or load a signature).

Also, as a minor note, there are a couple of function (tx_signers and aux_signing_data) that specifically handle the MASP case: we should see if we can collapse the MASP case to some other case to avoid this specific handling (like not passing an owner when the source of a tx is the MASP)

[grarco]

In addition, we should also review the signatures and wrapper_signature fields of args::Tx. We should be using these only when loading a tx from storage (with the tx command), so maybe it would be better to take them out of the general Tx args and move them into the specific args for TxCustom