Investigate returning account proofs as part of `SyncTransactions`

Currently, from the client, there are various levels to utilize FPI-related data on a per-transaction basis:

- You can describe what data you are going to need from an account before hand (specific vault or storage map witnesses) and those get fetched in bulk, alongside a corresponding account witness, before executing
- Anything that's not pre-loaded gets retrieved on execution runtime, but those are retrieved individually (so that adds up to one RTT per requested witness)
- You can also import "watched" foreign accounts, which gets you updates for those accounts on every `Client::sync_chain()` call. Then, on runtime, vault and storage map keys are retrieved from your local store. However, the account proof still needs to be retrieved during execution because no sync-related endpoint currently returns it.

It would be interesting to investigate the possibility of adding account proofs to a sync endpoint in order to let a client store an account proof on a sync. A simple way to add this could be to add an optional `account_witnesses` for the `SyncTransactions` request that returns account proofs for a limited set of account IDs. On the client we could already implement this by doing `GetAccount` whenever it syncs, but this is a bit wasteful and also incurs an extra RTT.
An alternative (IIUC this is what @bobbinth meant) could be to let the node operator configure which account proofs it can send, and this can be useful for faucets that can have callbacks which we know a client is going to need frequently (e.g., the native token faucet). This can be optimized in a way that becomes quite cheap for the node, and would alleviate pressure from a good amount of `GetAccount` which would then become redundant.