Improve deploy.sh

[naszam]

Rationale

Following #170 pattern I've extended the deploy.sh script behaviour to automatically edit config.sol by replacing the address with the deployed one (works with both pre-existing address(0) or with deployed spell address address(0x123).

[naszam]

@brianmcmichael @gbalabasquer I think this PR could be reviewed and merged on master in the meantime, as not pending on #166 discussion.

[naszam]

Unified together with #170 to automate further the spell crafting process by relying on Etherscan APIs to retrieve transaction hash, including commit add-on feat to automate end-to-end following dapp-init pattern.

[godsflaw]

I'm not sure if we should auto-commit this. First, I think this approach could be fragile (like one may have other staged changes for addition). Second, there is something that is a bit too sneaky about auto-commits without human review. Minimally, if we wanted to do this, I would say we should let this code run for a while and see if it encounters any failures under normal operation. But honestly, I think we may just want humans to be able to diff to review, add, and commit this manually.

[naszam]

yeah, this pattern is part of the spell crafting/reviewing automation endeavour, inspired by dapp init pattern.
In this specific case though, it could be a bit tricky as there are many moving pieces but one approach could be ensuring the changes have been actually edited in config.sol directly or better, running tests and if they pass commit.

[naszam]

Added tests check at deployed block in 8581a61

[olivdb]

Not a fan of the auto-commit either. If this is part of an automation workflow, it may be better to have the auto-commit done in an external script that calls deploy.sh imo.

[naszam]

As discussed in chat I'm testing some improvements to beef the script up with more checks before committing the changes as make test is a bit fragile an could return a zero status even if tests doesn't pass, but not opposed to handle the commit in an external script, I only think would be best for a CLI tool where the approach is more modular.

[naszam]

Let me know if a56a15a and b68131f give more assurance, the extra check was inspired by the dapp upgrade one (see here)

[naszam]

Discussing with @olivdb in chat, I've addressed the request of adding a way to stash and then reload local staging area in 2114dc1 (note that the stash would happen before the script makes edits and then it's reloaded before commiting in case the dev exit the commit edit prompt)

[naszam]

after some testing and further discussions, using trap we ensure we always exit with restoring the staging area.