evm: add WormholeCctpTokenMessenger abstract and optimize CircleIntegration

[a5-pickle]

PR Summary

• Add WormholeCctpTokenMessenger abstract contract for integrators that do not want to compose with CircleIntegration
• Leverage WormholeCctpTokenMessenger for optimized CircleIntegration
• Add various helper libraries
• Add forge tests

CircleIntegration Improvements

	Fork Test	Latest Test	Control Test		Fork Adjusted	Latest Adjusted	Improvement
Inbound	278,944	255,611	73,885		205,059	181,726	23,333
Outbound	365,874	357,024	207,775		158,099	149,249	8,850

Inheriting WormholeCctp vs Composing with CircleIntegration

	Composed Test	Inherited Test		Composed Adjusted	Inherited Adjusted	Inherited Benefit
Inbound	271,973	230,418		198,088	156,533	41,555
Outbound	389,673	341,201		181,898	133,426	48,472

Run make gas-report to generate above values. There is slight variance in computed gas numbers due to fuzzed inputs.

NOTE: Integration tests are removed in this PR. These will be added back in when we add another network like Solana.

[djb15]

Just to confirm, the reasoning for the storage slot layout is because this is going to be an upgrade of an existing deployment?

[a5-pickle]

Just to confirm, the reasoning for the storage slot layout is because this is going to be an upgrade of an existing deployment?

Yes exactly. Before the contract laid out the storage without specifying specific slots. But now that I moved some of these too immutables, I did not want the references to unused slots. I guess I could call the unused ones "gap". Which is preferred?

[djb15]

Just to confirm, the reasoning for the storage slot layout is because this is going to be an upgrade of an existing deployment?

Yes exactly. Before the contract laid out the storage without specifying specific slots. But now that I moved some of these too immutables, I did not want the references to unused slots. I guess I could call the unused ones "gap". Which is preferred?

No I'm happy to keep that as is. I think it's good to be clear that these slots were used before. Although I'd suggest wiping those storage slots to 0 in the initialiser of the new deployment just in case. And then on the next upgrade (the one after this) we could use those slots again. And then add sufficient docstrings/comments to explain what has happened with those slots, are they safe, etc. Happy to diff this change if you would like?