Security: Include the sink AccountId in the signed message for ToPublic transactions

[SupremoUGH]

Due to the bug where an attacker could perform a replay attack on someone's valid ToPublic post by changing the public AccountId, we needed to sign this last field together with the TransferPostBody.

Main changes:
-auth::sign and auth::verify now take BodyWithAccountsRef instead of TransferPostBody.

• transfer:

1. AccountId is now an associated type of the Configuration trait, instead of the Ledger one.
2. The Transaction enum in the ToPublic case now includes an AccountId.
3. TransferPost includes a sink_accounts field.
4. IdentityVerification::verify now verifies against a public_account as well.

• signer:

1. The function identity_proof also takes (a vector of) C::AccountId as input.

Misc:

• updated the clap dependency so it passes the lint after the latest rustup update.
• more on the identity_proof clumsy function: Identity Proof abstraction #325

Related PRs:

• Update the pallet: Security: Include the sink AccountId in the signed message for ToPublic transactions Manta#1032
• Update the sdk: Include Sinks in ToPublic Transaction sdk#102
• Update the sdk for the extension: Update manta-rs dependencies to 0.5.12 sdk#103
• Signer: Add sinks validation manta-signer#332

---

Before we can merge this PR, please make sure that all the following items have been checked off:

• Linked to an issue with discussion and accepted design OR have an explanation in the PR that describes this work.
• Added one line describing your change in CHANGELOG.md and added the appropriate changelog label to the PR.
• Re-reviewed Files changed in the GitHub PR explorer.
• Checked that changes and commits conform to the standards outlined in CONTRIBUTING.md.

[Apokalip]

@SupremoUGH I don't think we should keep the public polkadot key in the State, was talking with Charlie. The key is needed only for signing so the easiest way in the perspective for current signer is to be provided from the front end in its request for signing as it can already see and process all the public accounts from polkadotjs. Keeping the public key in signer just complicates how we save history and state as right now state is constructed based on a KeySecret from a mnemonic(signer account).

As for the signer-extension it would be easy to get and keep(cache) the keys as you have polkadotjs API directly or even the registed accounts in the extension itself.