[filler-v2, sdk, indexer]: fx strategy, intentsV2 refactor, partial fills indexing

[royvardhan]

Closes #283

[seunlanlege]

Btw does this support partial fills?

[seunlanlege]

We should also update the indexer to track partial fills

[seunlanlege]

Also i think fetching bids & executing them should be part of the placeOrder generator.

[seunlanlege]

BidManager.ts — Incomplete token price coverage
validateAndSortBids assigns 0 USD value because we agreed that the order.inputs -- the final escrowed tokens after executing predispatch calldata will be stables and WETH. And in 99% of the cases it will be USDC.
The need to compute USD values come from having WETH in the order. If this order's final escrowed tokens are WETH only then we can do with comparing the amounts without USD value. Simple integar comparisons. But let's say an order has WETH, USDC, and USDT involved. Then simple integar comparisons can fool the algorightm. This is why USD value is need to verify what is the final USD worth the user is getting.
Question: What tokens are we going to have in the order.inputs. What can be the legth of the order.inputs array? 1? (USDC only) 2? (USDC/USDT) 3?(USDC, USDT, WETH)

This is no longer the case, FX swaps means we will support any token to be escrowed.

BidManager.ts — Bid deduplication key too broad
Aren't we receiving one bid from a filler - whether it is a cross chain fill(full fill) or same chain fill(partial fill). Because that is what our strategies does right now. The partial fill (only applied to FX now) happens because of two reasons. First, the order usd value is too high, and the filler can only give X usd value maximum, because this is set in the constructor. Second, the filler does not hold enough balance (less likely but possible).

Prefer we just be defensive from edge cases as much as possible

Destination-initiated cancellation — not implemented
I believe this is a part of future prs.

Lets try to wrap everything up on this PR

IntentsV2.ts — Fee token cache never refreshes
I was under impression that we will restart this instance if we have any governance execution.

Downstream SDK users will not remember to do this

[seunlanlege]

Probably a good idea to allow getRecordedStorageSlot fallback to fetching the slot via debug_traceCall for FxSwaps