Add EIP-7594 (PeerDAS) related changes

[0x00101010]

Summary

Introduces updates to rpc and engine API definitions for EIP-7594, changes defined in ethereum/EIPs#9378

• Adjusts schemas for blob transactions (blob.yaml) and references to ensure consistency across all updated files.
• Added osaka.md to describe api changes

Notes for reviewers

This PR introduces backward incompatible changes to engine_getPayloadV4, that returns new BlobsBundleV2 with cell proofs instead of blob proofs

[ImTei]

I’ve added a few suggestions to slightly improve readability and clarity—mostly minor points for precision. None of them are strictly necessary, so please feel free to accept or ignore them based on your preference!

[Rjected]

have a question / request for clarification on the eth_sendRawTransaction semantics

[jimmygchen]

How much effort is it to make these endpoints return in SSZ encoding? I'd imagine JSON serialisation and deserialisation would take much longer with much higher blob count.

Given that engine has SSZ encoding capability (blob is already SSZ encoded), is it possible to support SSZ encoding the entire endpoint responses?

[jimmygchen]

Oh never mind - i think SSZ encoding the blobs already provide most of the savings on blobs.

actually, no, this is still hex encoded for JSON wrapped in a string, so it's still slow and expensive.

[jimmygchen]

Peter mentioned it before here:
https://x.com/peter_szilagyi/status/1841424117733478650

We should seriously consider doing this to support high blob count.

[nflaig]

We should seriously consider doing this to support high blob count.

the way the current engine-api is designed makes it almost impossible to add ssz as a wire format, yesterday the geth team mentioned they are working on a rest api following the beacon-api design, I think this is the right step forward, not only for blobs but also if we wanna bump up the gas limit