Remove duplication of deployment steps in executeFork, make a function that can do the genesis deploy from the ForkingManager

[edmundedgar]

We'd ended up with a lot of duplication of all the initialize steps passing a lot of similar arguments into various contracts:

• Twice in executeFork
• In lots of tests
• Again in the deployment scripts, which we also don't have tests for (although they're thorough about assert checks)

This PR channels all initialization through a single function, and creates a spawnInstance function that can be called against the ForkingManager implementation to do the initial deployment of all the other forkable parts.

Next step (apart from tidying up) would be to replace parts of the JavaScript deployment scripts with a call to spawnInstance.

[josojo]

yeah I think generally its nicer to do it that way.

Maybe the gas price for such big transaction are a little bit higher, but i think its fine. In the original deployment scripts, they did some deployments in a particular manner such that the bytecode of both bridge contracts (one in the L1, and L2) are the same. I never fully understood the reaosn for it. I think wiht your method, it might be that they are different. Not sure how much a deal that really is. Just a small heads-up of a potentially an issue.

[edmundedgar]

Great, I'll have a go at hacking this into the deploy and see if it works in practice.

I think the gas cost should be OK because it's only adding the proxies and initializing them. The part where you deploy the implementation contracts is still done from JavaScript and it's simple so I should be able to get the ongoing_deployments stuff working properly.