Add support for onboard + bridge where possible

[sisyphusSmiling]

Issue To Be Solved

The need to onboard in a distinct transaction creates UX friction and we would like to alleviate this friction where possible. The limitation when bridging from EVM to Cadence is one related to the availability of deployed contract. A Cadence contract is not available in the runtime until after the deployment transaction has been executed. In order to bridge an asset from EVM to Cadence, a defining bridge-owned contract must exist in the runtime from which a corresponding asset can be minted. However, since the defining contract isn't available until after the deploying transaction, the deployment and bridge transaction must then be separate, thus breaking the atomicity of the desired transaction.

Suggest A Solution

Explore if this limitation also exists for the EVM -> Cadence bridging path. If it does not, add support for onboard + bridge transactions along with test cases.

Context

Aligns with ongoing wallet product work
cc @JeffreyDoyle @lmcmz

[bluesign]

A Cadence contract is not available in the runtime until after the deployment transaction has been executed.

Little unorthodox but there can be few workarounds for that, such as you can mint and send on init, or callback etc. I will check bridge template contract, but should not be so hard.

[sisyphusSmiling]

Ah interesting idea @bluesign!

Update: After some discussion and brainstorming, it seems the limitation here is that a contract's init() block isn't executed until the end of a deployment transaction. This discord thread raised the question of changing that fact, but that will require more investigation. For now, my vote is to address this in the Cadence -> EVM path in #44 and put the issue of EVM -> Cadence in the backlog