add table of HF meta-EIPs

[cdetrio]

Adds a table with links to the HF meta-EIPs: #607 #608 and #606. An Informational EIP on the DAO fork remains to be written.

[holgerd77]

I would appreciate a lot if this could be merged, this is actually super-important structural stuff which is pretty hard to find atm (and these questions occur over and over again on the chat, ... "Where can I find information on hard fork x?").

And why not add a "Future Hard Forks" section, and link the pull request to the hard fork META EIP(s) there?

[axic]

@cdetrio can you rebase this?

@Souptacular @Arachnid can this be approved for merge?

[cdetrio]

@axic I was hoping to write the Informational EIP on the DAO fork before merging, just so that the table is complete.

[axic]

@Souptacular @cdetrio I think it might be worth merging this even before the missing one is written up

[pirapira]

@cdetrio I remeber you were saying somewhere that this was informational EIP rather than a meta EIP. Maybe change the tites?

[axic]

I'd actually argue that they are Core EIPs.

In the initial versions misleadingly I have used Meta as to referring that the EIPs are only umbrella EIPs, but after reading EIP-1 again, that specifies Meta as something describing a process.

[pirapira]

@cdetrio do you agree with @axic?

[axic]

EIP-1 mentions about informational that it "can be ignored". If all the individual EIPs about new opcodes, which specify a fork number are Core, the same should apply to the "fork specifications", which these documents are.

If those "can be ignored", then I'd argue all the EIPs introducing changes for forks should be "Informational".

Very likely the EIP categories should be instead revised as a proper solution 😉

[pirapira]

If @cdetrio agrees, I'll start relabelling these fork EIPs as Core. I'm not sure myself.

One possible line of counter argument goes like, each EIP says block.number >= BYZANTIUM_fork_block, and the fork EIPs just summarise the grep result. They can be ignored in favor of grep. This argument puts the list of forks in Core.

[axic]

I am sure we are discussing this at the wrong place, given this PR doesn't even touch the category field of those EIPs.

If all fork proposal EIPs contain a condition how (they don't contain the when) they activate (unfortunately not all do, for example https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7.md doesn't), that means it is required that every single Ethereum implementation contains them, but can opt to not turn it on.

[nicksavers]

This PR only relocates the HF links to a separate table. If the HF's themselves need to be updated, I suggest to use a different PR. This seems ready to merge to me.