Robustly check for precompile numbers in the tracing logic

[Xanewok]

Oh, this one has some history.

When we were using EthereumJS, we would do something like common.precompiles.length (I don't remember the exact API) to get the max precompile number. This was then used during tracing to figure out whether a call was a precompile call.

After we moved to EDR, I tried to remove as much EJS dependencies as possible. Some usages of Common, like this one, were trickier, so I just hardcoded a max value here. This is of course wrong: if you use an older hardfork that doesn't have the 0xA precompile, and you make a call to that address, Hardhat will tell you it was a precompile call, when it wasn't. I think this is a fine, temporary compromise, because this only affects user messages, not execution.

Once we finish porting this to the EDR side, this should be improved so that this comes from the EDR EVM somehow.

Also notice that there is another problem with this: after RIP-7212, the idea that there is a max precompile number, and that every address below it is a precompile, is wrong. So we should improve that too.

@Xanewok do you mind opening an issue about this, and linking it in the comment?

Originally posted by @fvictorio in #531 (comment)

In the VMTracer we check whether the address is a precompile by comparing the address with the "max precompile number". Rather than doing so, we should more carefully check depending on the hardfork used and not assume that the precompiles are contiguous.