feat: wire-up rfox staking

[gomesalexandre]

Description

This PR implements RFOX staking e2e.

• Wallet/custom RUNE address with newly added bech32 validateAddress in THOR adapter
• balance and fee asset balance validation, using react-hook-form. <TradeAmountInput /> has been touched in a non-breaking manner to now consume a form context if present with useFormContext or have a dummy useFormContext otherwise. We actually declare the form context up top in RFOX's <StakeInput /> and do anything with said consumed form context in <TradeAmountInput /> meaning this isn't a user-facing change despite the seemingly scary diff there
• Handles approval needed/allowance Tx firing
• Handles signing and broadcasting the Tx, including EIP1559 support
• Displays approval/estimate fees programmatically
• Displays share of pool
• Handles loading states gracefully
• Adds some market-data patching for missing FOX on Arb market data
• Adds some generatedAssetData patching for missing FOX on arb asset
• Adds FOX on arb and RFOX contract address + RFOX ABI constants (to be updated with latest once @0xean's https://github.com/shapeshift/rFOX/pull/43 goes in and v2 is deployed)
• Reintroduces wagmi for QoL (no need to reinvent the wheel when reading data with our own react-query hooks when battle-tested ones exist)
• Bumps viem from v1 -> v2 to work nicely with wagmi v2, and tackles all type errors and breaking changes (i.e function and arg name changes)

TODO:
- [x] tackle comments in this guy https://github.com/shapeshift/web/blob/7f85132b0f6b73cd77d8078ec060ebe5ae17da63/src/components/MultiHopTrade/components/TradeAmountInput.tsx
- [x] regression test added `useFormContext` and related changes in `<TradeAmountInput />` don't cause in regressions in current consumers
- [x] market patch FOX on Arb market data
- [x] approval fee instead of gas fee at input time when required
- [x] find a solution for `generatedAssetData.json` madness
- [x] share of pool?
- [x] Scrutinize react-queries that live in a wrong place currently (i.e lending)/should be generalized here, this is a bit messy on the query side and not really leveraging our current react-queries reusable queries for some
  - [x] 'estimateFees' (and consume the abstracted version in lending too after ensuring the implementation is line-per-line the exact same)
  - [x]  yeah no, we need the current mutation for proper loading state after click ~~send Tx mutation - probably not a now thing though it looks like we don't need a mutation at all here since we're not doing anything complex that requires a mutation - just move the logic to `handleStake` itself~~
- [x] Contract ABI and consumption
- [x] cooldownPeriod query
- [x] input
  - [x] estimate gas when approval *not* needed
  - [x] balance checks
  - [x] balance + fees checks as additional validate method
- [x] confirm
  - [x] approval step when required
  - [x] Tx broadcast
- [x] status
- [x] Record a final commented jam before opening this commenting on every row and ensuring data is there and things are happy re: balance checks, approval, spamming the delete key and re-inputting ensuring no race conditions etc. Go with the full flow e2e, including custom receive addy and its RUNE bech32 validation

Pull Request Type

• [ ] :bug: Bug fix (Non-breaking Change: Fixes an issue)
• [ ] :hammer_and_wrench: Chore (Non-breaking Change: Doc updates, pkg upgrades, typos, etc..)
• [x] :nail_care: New Feature (Breaking/Non-breaking Change)

Issue (if applicable)

closes https://github.com/shapeshift/web/issues/6737

Risk

High Risk PRs Require 2 approvals

Low/medium

What protocols, transaction types or contract interactions might be affected by this PR?

Testing

• RFOX flow is happy e2e, including
  • Approval needed (approval step is triggered and approval Tx is happy)
  • Not enough fee for gas
  • Not enough FOX balance for entered amount
  • Manual RUNE address (try with an invalid address too and ensure you cannot continue), as well as account RUNE addies
• Do a quick regression test of inputs in THOR LP, swapper and lending. No need to test these end-to-end, just ensure that you can still type amounts there without inputs being rugged

Engineering

• ☝🏽

Operations

• ☝🏽

Screenshots (if applicable)

https://jam.dev/c/ef9c0848-d978-459e-b209-5b57c4b1257f