Add experimental witness-generator-spec-cli

[jsign]

This PR adds a new experimental witness-generator-spec-cli which builds guest program input for live networks using the spec format.

Notes:

• I created it separately from witness-generator{-cli} stuff to not mix existing stuff. I think at some point they can be merged, or probably replace the old one, since ideally we should stop using the old format.
• We leverage as many structs from stateless-validator-common as possible. Still, some were missing and have now been added in schema.rs. Not sure where this will live eventually -- we could move the schema.rs stuff to ere-guests eventually so both workload and zkboost can leverage them as a neutral definition of things.
• It now uses both a CL and an EL RPC, compared to the previous EL-only RPC.

Regarding the last bullet, I think my goal is to have super-simple code for stateless input generation. Using EL-only RPC means having to do some gymnastics that we already suffered in ere-guests reg having to re-execute statelessly to get some fields (e.g. requests).

I think I would prefer to avoid all those complex things for two reasons:

• For now, only stateless Reth provides those generated results. I think we should avoid as much as possible, depending on ELs in particular, for our tooling. EL and CL RPC are neutral; we can switch to different implementations, and they have a spec.
• Avoid re-executing the block to generate inputs.

The current implementation is super simple, mainly does JSON-RPC calls, which usually 1:1 map into our neutral structs, the only exceptions are:

• StatelessInputs.public_keys, since it is a field invented for stateless guests and not part of RPCs
• The versioned_hashes aren't part of CL RPC. From what I've seen, kzg blobs commitments aren't part of CL RPC in Gloas, which looks a bit surprising to me. I would like to dig a bit more into whether there was a reason for this, since in Osaka RPC I think they were returned.

For both cases, we deserialise the RLP transactions and derive both things, which is quite simple anyway.

Next steps are I'm waiting for glamsterdam-devnet-4 to be healthy, and would like to test this out in that devnet. If this works correctly, we could incorporate this experiment more into workload to generate live network spec guest inputs for live networks (prob only Glamsterdam devnets).