Testing: add ability for `timestamp` control

The situation here is specifically the XEN tests where we execute the scenario which happens on mainnet: a single transaction mints a lot of XEN tokens from proxy accounts (tiny contracts controlled by the transaction origin).

To mint XEN tokens, one first calls `claimRank(uint256)` and then after this "rank" is over (at least a day) it is possible to claim tokens.

To replay this mainnet scenario we thus need the first block of the test which `claimRank()` and then, after at least a day, we send another tx to mint the tokens (for XEN this is the "attack" block). If we do this before the required time is over, the call to claim the tokens will revert and no storage will be written in the XEN contract (which is what we want).

In writing tests, I would find it logical to have it in the `Block`:

```python
block1 = Block(txs=[claim_rank_tx])
block2 = Block(txs=[attack_tx], timestamp=block1.timestamp+ 24*60*60)
blocks = [block1, block2]
...
blockchain_test(
...
blocks=blocks
)
```

However here that in the XEN test I don't really care about the specific timestamp: I care about the **relative timestamp** and I also only care that it is **larger than some minimum difference**. So the timestamp for this test does not have to be exactly that number. The way I wrote code above assumes I can read header data from `block1`. I am not sure if we can, about reading these dynamic parameters there is this related issue: https://github.com/ethereum/execution-specs/issues/1618

To narrow it down, for the XEN tests we must have a condition which states that after at least X time since tx A got included, then tx B can be included. For t8n we can set the timestamp of the environment. For `uv run execute remote` we cannot (in that case we have to wait), but if we control the engine API we can set the timestamp via `forkchoiceUpdated` in the `PayloadAttributes`.

Note that the XEN test itself should also have a check in this to verify the test runs correctly (the calls to the XEN contract to mint tokens must not fail). This "marker" in the test should thus tell EEST when certain transactions are allowed to be included on chain. I also notice that the proposed setup where this timestamp is a number in `Block` is likely not the best fit for this "relative marker" to tell EEST that two objects should be an amount of time divided by each other.

(Do not have write rights to add labels here, would otherwise have added test labels 😄 👍 )