[SC-425] Adding Circle CCTP support

[hexonaut]

Adding Circle CCTP support. Please note the naming scheme: anything labelled with just "CCTP" means the protocol itself and anything labelled with "CircleCCTP" refers to the instance that Circle controls.

CCTP is a general protocol so in theory it could be used by another operator.

[lucas-manuel]

Lets have a discussion on naming for this, logic is looking good though

[barrutko]

I'd go a step further in changing the naming from host/bridged to source/destination and only kept relayFromHost and relayToHost for compatibility reasons

[github-actions]

Coverage after merging SC-425-cctp-support into master will be

63.64%

Coverage Report

File	Stmts	Branches	Funcs	Lines	Uncovered Lines
src
ArbitrumReceiver.sol	80%	100%	75%	75%	15
CCTPReceiver.sol	80%	90%	75%	72.73%	19–21, 43
GnosisReceiver.sol	77.78%	100%	75%	62.50%	24–26
OptimismReceiver.sol	84.62%	100%	75%	80%	21
XChainForwarders.sol	50%	100%	50%	50%	122, 139, 169, 186, 198, 241, 70, 83

[hexonaut]

Guys regarding the L1/L2 thing, I've added a new task to refactor this repo and generalize it to a multi-bridge world. CCTP is the first case where we are not using a "canonical bridge", but this trend will probably continue and there are now cases where we need to bridge L2 to L1 such as the allocator module which needs to bridge L2 USDC back to Ethereum. It makes sense to refactor this repo and drop the adherence to L1/L2, domains being attached to 1 particular bridge, etc. So let's merge this in and the refactor can be addressed in a new PR.