Add support for building and executing durable TXs

[iulianbarbu]

Following up on the discord server thread related to how to handle durable TXs when dApps connect to wallet-connect compatible wallet https://discord.com/channels/492410046307631105/1045008929450627113. Will reiterate the context on this issue for visibility:

1. Some wallet-connect compatible wallets, e.g. Fireblocks, are MPC wallets that requires for some initiated TXs to be approved by a quorum of admins and shortly after signed by specific admins as well.
2. The process from 1) is variable in length and can take from minutes to days.
3. Given that Solana TXs can be executed in a window of roughly 2 mins after the recent blockhash of a TX (https://docs.solana.com/implemented-proposals/durable-tx-nonces#problem), the long process of approving and signing a TX requires the usage of durable TXs.
4. Using durable TXs means creating a regular TX that has the AdvanceNonce IX prepended, which requires the existence of a NonceAccount with the authority set to one of the TX signers.
5. To create durable TXs within the dApps each dApp must use a nonce account that has as authority one of the signers of the TXs, which most probably will be the user connected wallet.
6. These NonceAccounts can be a) created by users and provided to the dApps, b) managed by the dApps to hide the complexity from end users or c) handled by the wallets by fetching the regular raw TXs from the dApps and change them to durable, besides the signing and broadcasting to the network. c) would be ideal for both dApps and users and it's something which scales better. From my understanding from discussing with Fireblocks on the subject, they already have business logic that support c). Solib provides the signAndSendTransaction primitive that shouldl kickstart the mutation of the raw TX to a durable one on Fireblocks side plus the TX approving, signing and broadcasting, but by looking at the implementation it seems that the method relies on the Solana validators sendTransaction RPC method, not on the wallet implementation of a solana_sendTransaction RPC method implemented on the relay server (please correct me if I am wrong). Also, Fireblocks is one of the many MPC wallets that might implement walletconnect v2 standard for Solana and the same assumptions around c) might not stand for all wallets.
7. NonceAccounts are owned by SystemProgram so querying for them using Solana validator RPC methods (getProgramAccounts being the only option from my understanding) brings significant latencies given the number of accounts owned by the SystemProgram.
8. dApps that want to take matters in their own hands must manage NonceAccounts creation/indexing for users wallet addresses, to enable the support for durable TXs that will be signed and broadcasted to the network on the wallets side.
9. This is not something that scales very well (especially if all dApps will create nonce accounts for same users and index these nonce accounts in their backend to avoid 7.).
10. Something which can improve 9) is if the querying for nonce accounts that have as authority the dApp connected user can be done in a more efficient manner (through some Solana primitive maybe?) or if the nonce account management will be deferred to the wallets.

I am curious to see how the reasoning process unfolds while progressing towards a decision and solution (one from 6. or others, not specified in this issue).