add gasLimitMultiplier to fireblocks and privatekey wallets

[samlaf]

Fixes errors we were getting on avs-sync with txs reverting due to running out of gas.

@ian-shim this is a super simple gasLimitMultiplier parameter that the user can set (so we can test whether 1.1, 1.2, etc works best for different cases). hardcoded the default as 1.1

[samlaf]

throwing this into this PR if you don't mind

[samlaf]

Realizing we prob want this logic in the txmgr instead.... will create another PR.

EDIT: there are a few options here, so will wait for your feedback:

1. wallets automatically bump by 10% (what this PR is doing)
2. wallets have a new function SendTxWithGasBump(buffer float64)
3. txMgr's send() function will bump by 10% before sending to wallet.send()
4. txMgr will have a new function sendWithGasBump

[ian-shim]

Realizing we prob want this logic in the txmgr instead.... will create another PR.

EDIT: there are a few options here, so will wait for your feedback:

1. wallets automatically bump by 10% (what this PR is doing)
2. wallets have a new function SendTxWithGasBump(buffer float64)
3. txMgr's send() function will bump by 10% before sending to wallet.send()
4. txMgr will have a new function sendWithGasBump

I think wallet should remain simple/minimal interface to interact with chain. The complexity for handling gas cost, replacing stalled transactions, etc. should be the responsibility of the caller. I think option 3 with configureable gas bumps is the most preferable

[samlaf]

Realizing we prob want this logic in the txmgr instead.... will create another PR.
EDIT: there are a few options here, so will wait for your feedback:

1. wallets automatically bump by 10% (what this PR is doing)
2. wallets have a new function SendTxWithGasBump(buffer float64)
3. txMgr's send() function will bump by 10% before sending to wallet.send()
4. txMgr will have a new function sendWithGasBump

I think wallet should remain simple/minimal interface to interact with chain. The complexity for handling gas cost, replacing stalled transactions, etc. should be the responsibility of the caller. I think option 3 with configureable gas bumps is the most preferable

sgtm! Closing in favor of #167