Route FlowToken requests to WFLOW

[sisyphusSmiling]

Issue To Be Solved

Currently, WFLOW is blocked from being bridged to Cadence since it only exists as an ecosystem primitive in EVM without analogous use case in Cadence. Additionally, moving FLOW between VMs via the bridge is only allowed en route to EVM and is blocked on the route back to Cadence. This is a fragmented pattern and can create unclear edge cases.

Proposed solution

Since there exists a native interface for depositing & withdrawing FLOW between VMs without reliance on the bridge, the proposed solution involves treating requests to move FLOW between VMs via the bridge as requests to wrap & unwrap FLOW.

Moving FLOW from Cadence -> EVM: Wraps FLOW and deposits in EVM to the named recipient
Moving FLOW from EVM -> Cadence: Unwraps FLOW from the calling COA returns a FlowToken Vault

The only caveat here is to check with Flow Wallet and Flow Port to ensure that they use the intended interface to bridge FLOW - via EVM.EVMAddress.deposit() and are not using the bridge to deposit FLOW to EVM recipients. This is likely to be true, but deserves a quick discovery.

[sisyphusSmiling]

Following #137, the following steps will be required to enable FlowToken <> WFLOW handling:

1. Update bridge contracts affected by Add wflow handler #137
   1. FlowEVMBridgeUtils
   2. FlowEVMBridgeConfig
   3. FlowEVMBridgeHandlerInterfaces
   4. FlowEVMBridgeHandlers
   5. FlowEVMBridge
2. Remove current FLOW association with origination EVM address from FlowEVMBridgeConfig.registeredTypes & .evmAddressHexToType
3. Add WFLOWTokenHandler to FlowEVMBridgeConfig.typeToTokenHandlers
4. Enable WFLOWTokenHandler

[sisyphusSmiling]

Contracts have been updated on Testnet & Mainnet to support this bridging path. Confirmed correct behavior bridging to and from EVM.