feat: implement ETC networks configs ECIP1078

[meowsbits]

This reverts commit f9c254e, with the effect and intention of only essentially re-opening #128.

---

The story goes:

• branch with +ECIP1078 changes (miner: fix miner application of DAO state core-geth#128)
• next branch for refactoring built, dumbly, on top of that one, Merge/foundation master 20200709 core-geth#140
  • this branch realizes that it was dumb to include 1078, flatly reverts config file changes (etclabscore/core-geth@f9c254e)
  • gets merged

...so ECIP1078 was introduced to master and removed with same PR (and #128 unintentionally closed).

This PR undoes the disabled ECIP1078, effectively proposing to enable it. Maybe even for real this time.

[tzdybal]

LGTM

[soc1c]

LGTM, a release would be appreciated

[meowsbits]

ECIP1078 is still in Last Call state.

I'm not sure this should have been merged, and would have probably preferred it to remain a reference implementation until the ECIP is marked as Accepted.

Beyond that, cutting a release which includes block activation specifications which have not been finalized is bad form; we should wait until Accepted (like we should have to merge the specification).

https://github.com/ethereumclassic/ECIPs/blob/master/_specs/ecip-1078.md

[meowsbits]

^ cc @tzdybal @soc1c @ChunFuYang

[soc1c]

@meowsbits Last call period end is after the activation on the testnets. Maybe we can agree to cut a release without mainnet block number but for the testnets? What do you think?

[meowsbits]

That sounds like an acceptable compromise to me.

Although I will say that having the Last Call period end after the activation on the testnets was probably not the ideal way of structuring this.

Lesson learned for future: Let's specify activations to happen after the specification drafts themselves will have been finalized.

[soc1c]

We did that on purpose because we have another 3 months till mainnet activation. But I see what you are saying here.