refactor: Refactor Wallet Implementations

[lewis-sqa]

Description

• Rewritten wallet types.
• Removed isAvailable in favour of returning null during wallet setup (which is now async).
• Renamed selector option wallets to modules.
• Modified selector.wallet() to be async.
• Improved wallet switching logic. Existing wallets are only disconnected when we successfully connect to the new one. This is also the case with NEAR Wallet.
• Rewritten wallet-controller to wallet-modules & wallet-instance.
  • Removed the need for emitting "connected" and "disconnected" by decorating connect and disconnect.
  • Filtering wallets that aren't available is no longer a UI responsibility.
  • Wallet behaviour is now async. This makes it possible to initialise clients before returning methods and simplifies connect.
  • Setup logic now calls getAccounts instead of connect to validate the connected status.
• Aligned wallet implementations
  • Ledger now uses a similar signTransactions method to Math Wallet.
  • Disconnecting the Ledger device no longer disconnects the accounts, aligning with the lazy connection behaviour.
  • All wallets now use an _state variable to hold references to clients and subscriptions.
  • Moved isAvailable logic into the setup method.
  • Added chainId parameter to WalletConnect to avoid confusion when using custom network configuration.
  • Renamed appMetadata back to metadata for WalletConnect.
• Removed "wallet not installed" use case, simplifying injected wallets.
• Updated Custom Wallets guide.

Future Improvements

• Throw if we detect a duplicate wallet id during setup.
• Add checks around network configuration between options.network and wallet network.
• Inject a platform/device dependency for WalletModuleFactory to avoid wallets having to import is-mobile.
• Gracefully handle wallets that might throw during setup (e.g. should they break without changes from our side in the future).

Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings

Type of change. This type of change is the main reason for the PR.

• FIX - a PR of this type patches a bug.
• FEATURE - a PR of this type introduces a new feature.
• BUILD - a PR of this type introduces build changes.
• CI - a PR of this type introduces CI changes.
• DOCS - a PR of this type introduces DOCS improvement.
• STYLE - a PR of this type introduces style changes.
• REFACTOR - a PR of this type introduces refactoring.
• PERFORMANCE - a PR of this type introduces performance changes.
• TEST - a PR of this type adds more tests.
• CHORE - a PR introduces other changes than the specified above.

Breaking changes

• BREAKING CHANGE - SPECIFY: _______
• NO BREAKING CHANGE - this PR doesn't contain any breaking changes and it's backwards compatible