feat: add reth test-vectors compact --write|--read

[joshieDo]

closes #11924

1. Adds another CI job that will on every PR:
   a) checkout main
   b) randomly generate and serialize to disk many different type vectors with Compact (eg. Headers, Transaction, etc)
   c) checkout pr
   d) deserialize previously generated test vectors
2. Adds static test_decode tests for transaction types, receipt and headers.

This ensures that the PR does not introduce a non-backwards compatible change to a type that implements Compact.

For now, the CI job is disabled. It would fail since main does not have the command. It will be enabled later on.

--

There's some follow-ups to be done here:

• optimism: feat: add op-reth test-vectors compact --write|--read to CI #11994
• a few todos on manually implemented Compact types

    // Signature todo we for v we only store parity(true || false), while v can take more values
    // Bytecode, // todo revm arbitrary
    // MerkleCheckpoint, // todo storedsubnode -> branchnodecompact arbitrary alloy-trie
    // StorageTrieEntry, // todo branchnodecompact arbitrary alloy-trie
    // StoredSubNode, // todo branchnodecompact arbitrary alloy-trie

[mattsse]

are these helper functions to generate test vectors and we run this once to get static test vectors
or are these always generated?

[joshieDo]

we can do both

are these always generated?

I was leaning towards this one. during PR CI, generate with main branch, and read with branch

[mattsse]

looks like the only thing missing here is some op feature combination