### Description
Some tweaks to get checker tooling working with ICA ownership:
- changed the `inferCallSubmissionTypes` logic to no longer mutate
`this.calls`. Some weird side effects were occurring, especially where
the ICA logic would try to pop and push from `this.calls` while also
looping over it. This is also why I made it serial again. I ended up
moving away from mutating this.calls entirely during the iteration, so I
guess moving back to doing it concurrently can be done again. Happy to
do this if it feels good to - the only reason I haven't is this wasn't a
place where we had huge inefficiencies and it'd complicate the code a
little
- Got it working where a Safe on chain A owns an ICA on chain B
These are the flows I tested:
- sepolia is the "owner chain"
- deployed a warp route between sepolia and alfajores. Changed the
alfajores owner to an ICA owned by the sepolia deployer key. Tested
transferring ownership back from this to the deployer.
- Did the exact same as above, but now with the ICA being owned by a
Safe on sepolia
- Transferred ownership of Alfajores core contracts to and from the
sepolia-deployer-owned ICA
These are some raw notes that may be of interest of what I did
https://www.notion.so/hyperlanexyz/ICA-playground-996cf28aea1649a18051afb8bb82acb2
This doesn't auto-deploy ICAs. An ICA is expected to have been deployed
already, and then just configured in `owners.ts`. Check-deploy figures
out that it's an ICA and does all the rest. This is fine imo in the
short term as I only imagine us using ICAs on two chains (inevm and
viction) for the time being.
### Drive-by changes
<!--
Are there any minor or drive-by changes also included?
-->
### Related issues
<!--
- Fixes #[issue number here]
-->
### Backward compatibility
<!--
Are these changes backward compatible? Are there any infrastructure
implications, e.g. changes that would prohibit deploying older commits
using this infra tooling?
Yes/No
-->
### Testing
<!--
What kind of testing have these changes undergone?
None/Manual/Unit Tests
-->