Monorepo: Unify/Refactor getHardforkByTTD,... Options and Common Methods

[holgerd77]

Ok, so this is a somewhat small task we really should do for breaking releases as well, since things are so chaotic right now.

I think I've got a proposal here which is both manageable and un-wiring.

To recap, we have:
-Common method setHardforkByBlockNumber(blockNumber: BigIntLike, td?: BigIntLike, timestamp?: BigIntLike)

• Common method getHardforkByBlockNumber(blockNumber: BigIntLike, td?: BigIntLike, timestamp?: BigIntLike)
• Block option hardforkByBlockNumber (boolean)
• Block option hardforkByTTD taking precedence over the former if used
• Common hardforkIsActiveOnBlock() / activeOnBlock() taking in only block number and having just one (DAO) usage (so: not even a "use case")
• hardforkByTTD?: BigIntLike option for VM
• hardforkByTTD?: bigint option for VM.runBlock() (haha, it's getting ridiculous 😂)
• _hardforkByBlockNumber: boolean and _hardforkByTTD?: bigint internal VM properties. lOL. Double ROFl.

Ugh.

Ok, all pretty chaotic, but I think fixing this is not as rough as one would think.

So what we can do here is:

1. Add a new dict interface hardforkByOpts or similar to Common like:

interface hardforkByOpts = {
  blockNumber?: bigint,
  timestamp?: bigint,
  td?: bigint
}

(I would be a fan here (and everywhere else) to limit to BigInt and remove the BigIntLike thing)

Then we can simplify and better name the Common methods to:

• Common.setHardforkBy(byOpts: HardforkByOpts)
• Common.getHardforkBy(by: HardforkByOpts) // by or byOpts (aligned of course), both works I guess

(open for better/alternative namings but I liked this after some thought and look)

2. Block options should be unified to - name suggestion! - setHardfork: boolean | bigint with the same semantics as the previous two options

3. Same alignment for VM and VM.runBlock() as well as internal properties:

• setHardfork: boolean | bigint as VM option
• setHardfork: boolean | bigint as VM.runBlock() option
• _setHardfork: boolean | bigint as internal property

4. As far as I've had a look I think these Common hardforkIsActiveOnBlock() / activeOnBlock() methods can both be completely removed. These only work for the outdated block number case anyhow and can also easily be replaced, by hf comparison or the hardforkBlock(...) method.

I think the above is a good compromise between either staying in the current chaotic state and directly try to throw TTD out. Not too much work and this should already bring much needed clarity.

I also think this has the potential of pre-actively eliminate bugs we might still have in our code, e.g. by not taking all possible switch options in on forgotten occassions. This task is a good opportunity to have a look there and eventually update (by e.g. passing in a forgotten timestamp value, case by case decision).

[holgerd77]

Closed by #2798 and #2800