Repo Structure

[michaelkaplan13]

Context and scope
In order to promote a more maintainable repo structure for smart contracts built on top of both AWM and Teleporter, and create a clear single entry point for anyone looking to learn about those contracts, we should structure the repo in such a way that provides an intuitive home for current and future projects.

Also related, "Warp" and "Teleporter" going forward will be referred to as "Avalanche Interchain Messaging (ICM)", so we should begin to have the repo reflect that.

Discussion and alternatives
This repository (teleporter) can become avalanche-icm-contracts to be the clear home for smart contract publish that build on top of the Avalanche ICM protocol. This includes the existing Teleporter protocol, but could also in the future include protocols for EVM event importing, ACP-77 staking contracts, etc.

A rough breakdown of how the repository could be structured is:

audits/
lib/
contracts/
	Teleporter/
		Interfaces/
		Upgrades/
		Utils/
			ReceiptQueue
			ReentrancyGuards
			SafeERC20TransferFrom
	ICTT/
	Utilities/
		AccountRegistry/
		ValidatorSetSig/
scripts/
e2e-tests/
	Setup/
	Teleporter/
	ICTT/

This is a very rough high level suggestion. The exact names can be determined by the implementer.

Open questions

• On a go forwards basis, how can we make clear that the Teleporter contract should only be deployed via the static Nick's method transaction for official major release versions, which doesn't necessarily reflect the changes in main or in minor/patch releases?
• How do we iteratively move the "teleporter" name to follow the more standard "Avalanche ICM" conventions? (Should not be included in this issue either way).
• Where does the teleporter-cli fit in the above structure, or can it be removed?
• When should the Avalanche ICTT contracts be moved in? Can be now or in a later sub-issue.