Clarify hard fork names in transaction tests

Currently, in the TransactionTests, multiple names are confusing:

See for instance this logic I implemented in my toy client:

    /** Returns the starting block height for the given version. */
    private static int blockHeight (String version) {
        return switch (version) {
            case "Byzantium"            -> BYZANTIUM.startBlock;
            case "Constantinople"       -> CONSTANTINOPLE.startBlock;
            case "ConstantinopleFix"    -> CONSTANTINOPLE.startBlock;
            case "EIP150"               -> TANGERINE_WHISTLE.startBlock;
            case "EIP158"               -> SPURIOUS_DRAGON.startBlock; // (*)
            case "Frontier"             -> FRONTIER.startBlock;
            case "Homestead"            -> HOMESTEAD.startBlock;
            case "Istanbul"             -> ISTANBUL.startBlock;
            default -> throw new AssertionError("unreachable");

            // (*) if interpreted as EIP-161 that supersedes EIP-158
        };
    }

The left column are the names used in the transaction test JSON files.

1. The “EIP” names should be the proper forks name, and “ConstantinopleFix” should probably be called “SaintPetersburg”.
2. I think EIP158 was never actually implemented on mainnet, as it was superceded by EIP-161. I’m not sure how a client is supposed to test the “EIP158” results. Was EIP158 deployed earlier on test nets perhaps?
3. Was the “Berlin” fork skipped on purpose because all results are expected to be the same? If not, is there some automated way to run the tests in a client at a Berlin block height and update the test files?

[winsvega]

the transaction tests are being reworked. fork names identical to state tests.

[winsvega]

Now we have some invalid transactions in state tests.

For me personally, just having the JSON files is useful already. Parsing them is not difficult. Maybe it doesn't fit with how this repo is used with retesteth, but that's just my perspective :)

So to the other devs. But have you ever thought how those JSONs appeared initially? Its not handwritten. We used aleth implementation. Now to generate the tests I can write my own transaction implementation but that would be bad as I might make a mistake. Like ori just recently found what might be a bug in my difficulty formula on edge case.

What we need is a way to ask client if it considers certain transaction valid struct or not. But devs prefere their own tests or just ready made jsons