Correctly encode approval interactions for USDT-like tokens

[MartinquaXD]

Description

Alternative to #4340

USDT is a bit special because it is one of very few tokens where the approve() function requires you to set the allowance back to 0 before you can alter it again to avoid a vulnerability (see here).

Changes

This PR adjusts the driver's approval encoding logic such that it checks whether the regular approve() call would revert. In case that happens it encodes an approve(0) and approve(desired_value) to be compatible with this security measure / quirk.
That way we support all those tokens on all chains without needing any extra configuration parameters or hardcoded values. The downside is 1 extra RPC call every time we have to increase an approval which is extremely rare so it's fine.

How to test

Converted an existing USDC -> USDT order fork test to be a USDT -> USDC test. This test fails without the PR's change.

[gemini-code-assist]

Code Review

This pull request updates the approvals logic to support tokens like USDT, which require resetting allowances to zero before they can be increased. It also updates the end-to-end tests to use USDT to validate this new behavior. Feedback was provided regarding the approvals implementation, specifically pointing out that the use of a HashMap for aggregation is redundant and introduces non-determinism. Furthermore, the logic should be corrected to avoid emitting an unnecessary approval interaction when the current on-chain allowance is already sufficient.