Add optional transaction simulation to functions returning transaction requests

[bayological]

Description

The SDK currently builds transactions that consumers can sign and send at a later stage. As the SDK does not take care of submitting these transactions, it's hard to handle any smart contract errors that may be encountered. We need to add an option to simulate these reactions to detect any potential errors and then return a useful message to help consumers move forward.

This is an example of estimate gas failing due to an error:

We need to extract the value of the reason property, which will be the revert message from the smart contract.

Acceptance Criteria

• [x] Functions that return transaction requests(increaseAllowance, swapIn, swapOut) have an additional bool parameter that defaults to true to determine whether or not the transaction should be simulated
• [x] These functions simulate transactions using estimate gas in a try/catch block when flag is set to true
• [x] A shared function is added that takes in estimate gas error and returns the inner exception message is added.
• [x] An internal mapping is created that maps some revert messages to a more user friendly message (circuit breaker tripped, trading limit exceeded, amountOut/In not enough)

[bayological]

I hit a minor obstacle while testing this code in the SDK. In scenarios I set up to trigger an error, the code throws exceptions before reaching the catch block in the simulation check, preventing us from receiving the modified error message.

This led me to look into how the "populate transaction" code worked. We use this function in all calls that return a transaction request: https://github.com/ethers-io/ethers.js/blob/master/packages/abstract-signer/src.ts/index.ts#L197. After reviewing the code, I saw that the "populate transaction" function also calls "estimate gas" when the transaction limit is not set. Since we neither expose the option to set a custom transaction limit nor set it ourselves, the "estimate gas" function will always be invoked as long as we use "populate transaction". As a result, we don't actually need to call "estimate gas"; instead, we could catch any errors thrown by "populate gas" and then extract and update the error message.

However, doing this is not necessary because developers handling the error can already see the revert reason within the error object. So, for now, I'm closing this issue. If we reach a point where users struggle to understand the errors, we can revisit this.