Warp Route extensions should be idempotent

[nambrot]

Warp route extensions are meant to be done idempotently. That means that if you run the same warp apply command with the same deploy config and artifact references (WarpCore config), the outcome should be the same, whether or not whether the user actually submitted the transactions of the first apply run. Unfortunately, that is currently no true.

Specifically, only upon the first invocation, a warp apply command makes it past this if statement

hyperlane-monorepo/typescript/cli/src/deploy/warp.ts

Lines 568 to 574 in 228f7c3

	let extendedConfigs: WarpRouteDeployConfig = objFilter(
	warpDeployConfig,
	(chain, _config): _config is any => !warpCoreChains.includes(chain),
	);
	const extendedChains = Object.keys(extendedConfigs);
	if (extendedChains.length === 0) return [];

After that, executeDeploy will actually deploy the contracts on the new chains, which will make extendedChains to be an empty array.

Only on the first run, we do (rather oddly) a mutation of the remoteRouters table. On the second run, we hit the code path only in [updateExistingWarpRoute](https://github.com/hyperlane-xyz/hyperlane-monorepo/blob/228f7c3d16098f217a8cd9663df27265a2ea8561/typescript/cli/src/deploy/warp.ts#L612). Since the original config does not include the router table, it will not create the enrollment transactions in

hyperlane-monorepo/typescript/sdk/src/token/EvmERC20WarpModule.ts

Lines 146 to 148 in 26fbec8

	if (!expectedConfig.remoteRouters) {
	return [];
	}

The objective of this ticket is to streamline the warp apply router enrollment handling to
a) Allow warp apply to be idempontent. I.e. no matter what pending transactions are, when warp apply is run
b) Explicitly test these scenarios of (all without having to specify the router table manually in the warp deploy config
i. extending a warp route in one shot
ii. extending a warp route later
iii. extending a warp route after a router was manually unenrolled

For that we probably need to
a) Reduce the number of places where we "infer" the intended remoteRouter table to only 1 place. I.e. remove this extra enrollRemoteRouters function (but maybe there is another reason for why its in there?)

Questions:

1. Why do we do this mutation of the warp route config remote router table instead of deriving it from the routers passed in [deployedContractsMap](https://github.com/hyperlane-xyz/hyperlane-monorepo/blob/228f7c3d16098f217a8cd9663df27265a2ea8561/typescript/cli/src/deploy/warp.ts#L745)

[nambrot]

The PR for this should absolutely include tests for these scenarios of not finishing the enrollments of the previous invocation and it still working