Articulate EIP parameters and feature implementations

[whilei]

Refactors chain configuration and respective feature implementations to use IsEIP<NUMBER> definitions and methods, instead of Is<HardForkName>, whenever possible. Doing so attempts to address problems of ambiguity and complexity in chain configuration and feature implementation.

As I see it, this refactoring has a few benefits:

1. More descriptive code. By describing and implementing client configuration with feature-based definitions, instead of "arbitrary" and opaque hard-fork feature groups, feature implementations become clearer. This improves the code's legibility and accessibility, separates logical concerns, documents specification references, and allows more granular testing.

2. It's more interoperable. Clients choosing to adopt a subset of EIP-derived changes, normally inextricably bundled in a hard-fork identity, are able to toggle individual features. This establishes an extensible pattern that alternative implementations can use to build clients with supersets or subsets of features.

3. It doesn't break backwards compatibility. All existing hardcoded or external chain configurations continue to operate as expected, tests pass, and named hard-fork keys and methods take priority.

What this patch doesn't do:

1. Handle every feature ever introduced via the EIP/Hard-fork processes. For example, of the changes introduced with the Homestead fork, only EIP 7's DELEGATECALL has been extracted, and the DAO fork is untouched. Just low-hanging fruit.

2. Implement correlated refactoring across the tests/[testdata/**/*.json] tests and test runners. These are located in a submodule, very numerous, very opinionated toward the hardfork schema, and their relevance and applicability is not impacted by leaving them as-is.

3. Implement new distinct difficulty calculators for EIP100 (Change difficulty adjustment to target mean block time including uncles) vs. EIP649 (Delaying the difficulty bomb and reducing the block reward), which were two modifications to the difficulty algorithm introduced simultaneously at the Byzantium hard-fork. I'm trying to limit the scope of changes to introduce as little new consensus logic as possible.

4. Attempt to differentiate features beyond the specifications of EIPs.

5. Move beyond supplemental modification of existing patterns.

---

For review and reference, I compiled this gist along the way.