[Transfer] Support PA v2 migration mechanisms in front-end

[jurevans]

We need to support the basic process of allowing a user to convert their existing Anoma resources into a potential PA v2 resource in the event of some catastrophic security issue. The basic mechanisms should be in place and verifiable.

Ideally, the front-end should be able to replicate the e2e tests in the backend for migrations. See the e2e tests merged in from this PR: https://github.com/anoma/anomapay-backend/pull/172

• Add ability for the front-end to support new Transfer logic https://github.com/anoma/anomapay-backend/blob/860341c62db2ce9bdc62460df589232026949ca6/simple_transfer/transfer_library_v2/src/lib.rs#L28-L33

  • NOTE While we will need a separate v2 logic class for constructing v2 resources in order to support an e2e fork/migration test, it would seem that we could just update it in place (change existing logic methods/parameter builders/etc) at the time of the emergency, because under no circumstances should the user be allowed to construct new transactions for the compromised PA. To support a migration flow in an e2e test, however, we need both, and since we need both, we may just have a constant which hardwires the active logic/parameters to use for new Tx

• Support building v2 resources from frontend, and their respective witness data (along with any changes to their respective types in front-end)

• Authorization of actions / fees, and submission to backend

• Initially, invoking an e2e test via CLI is the best way to test & verify this, and we can follow anomapay-backend e2d tests for migrate tx). We don't want UI in place until it is needed, and that should be a separate issue and left out of production view for obvious reasons)

• construct_migrate_tx

NOTES

• I think it would be a good idea to define core Resource Logic methods in a similar fashion to the backend, for both V1 & V2 (most importantly for V2)
  • The arm-bindings crate could be moved to a Cargo workspace and provide ARM bindings (currently provided) and then wasm builds for each Transfer Logic/Witness version for app logic, then Front-End can import only from the specific, V2 transfer lib version in the event of a fork:

transfer/
  -> arm-bindings/
  -> transfer-v1/
  -> transfer-v2/