feat: add "zkvm" flag that reduces VariableList to a manageable size by zkVMs

[unnawut]

What are you trying to achieve?

This PR adds "zkvm" feature flag so that external programs can config ream codebase in the way that can be run on zkVMs.

In this PR, the feature flag would drop VariableList that are 2⁴⁰ in size down to 2²⁹ when enabled, so that 32-bit zkVMs can work with our BeaconState.

See ReamLabs/consenzero-bench#24 for how this feature flag is used.

How was it implemented/fixed?

The BeaconState contains some "zkvm" features where 32-bit zkVMs would fail on constructing a VariableList larger than 2³² size (i.e. 2⁴⁰). When "zkvm" feature is enabled, it would construct the BeaconState with 2²⁹ list instead.

To remain conformant with consensus-specs, this feature needs to be used with the modified ssz_types crate at https://github.com/ReamLabs/ssz_types/tree/magic-extended-list where the crate would detect 2²⁹ as a magic number when computing the root hash, and it will compute as a 2⁴⁰ list root instead.

Tbh I'm not sure I actually want to add this to ream's main codebase, but it's needed to run ream-consensus on zkVMs with correct results. If it's not ideal to merge, I'm happy to keep it as a long running zkvm branch on ream as well. Happy to discuss this and also in case anyone has a better idea to manage these differences.

To-Do

• I have read CONTRIBUTING.md.
• This PR uses conventional commits.

[KolbyML]

Left some feedback

[jihoonsong]

Having a long standing branch is a pain. Given that Beam chain client itself is a prototype, I think it's okay to merge it.

But this is apparently a tech debt. This issue is coming from ssz-types and I do think this workaround is a temporary stopgap. We need to modify ssz-types and relevant libraries properly or use other SSZ implementation whether it be ours or Grandine's or whatever.

After we become able to run Ream in 32-bit zkVMs, I think it's a good time to work on a proper solution.

[jihoonsong]

Great work!

[KolbyML]

I am good with this change