Conform to https://eips.ethereum.org/EIPS/eip-7892, in order to pass EEST v5.1.0.

Suggested logic:

1. EEST blockchain_test fixtures now come with a new blobSchedule (as specced out by the EIP) and a network field, which is sth like OsakaToBPO1AtTime15k
2. For tests which have blobSchedule, it will be parsed to produce a mapping fork -> blob params
3. The network field, if one of the predefined transitions like OsakaToBPO1AtTime15k, will be recognized. The transition time will be used to find blob params in that mapping, for each block.
4. If not found in the map, hardcoded blob params will be used as before (only up to Prague)
5. For purposes other than blob params, "forks" like OsakaToBPO1AtTime15k are just treated as Osaka, being the most recent non-BPO fork preceding the active fork for blob params

Beyond EEST v5.1.0, network field parsing (3.) may be substituted by parsing <Fork>Time fields similar to format given in the EIP itself, if that is chosen to be put in the blockchain_test fixture format. (5.) would then become irrelevant as special network values would not be used anymore.