feat: rlp.ParseTree()

[ARR4N]

Why this should be merged

The types.Header fields of both coreth and subnet-evm have been modified such that their RLP encodings (i.e. block hashes) aren't compatible with vanilla geth nor each other. Supporting both coreth and subnet-evm (let alone backwards compatibility) via "passive" modification of RLP (i.e. by modifying fields) is proving to be extremely difficult, if not impossible. This PR is the first step towards an active, and therefore controlled, approach.

How this works

The (R)ecursive element of RLP allows it to be readily parsed into a tree, which is introduced as the rlp.ParseTree([]byte) ItemNode function. The only node types are the so-called "items" of byte arrays (also called "strings"), positive integers, and lists of other items. The parser is implemented in rlp/tree.libevm.go, which should be reviewed first.

The intent is that libevm-style extra payloads will have RLP hooks that manipulate trees after encoding (to add their own items and remove unused ones) and before decoding (to invert the encoding changes). A follow-up PR will add re-encoding of trees.

How this was tested

Tree parsing is run against all existing RLP-encoding tests merely to ensure no errors. A more comprehensive set of fuzz tests builds trees and concrete values n parallel, ensuring that the former is recoverable via rlp.ParseTree(rlp.EncodeToBytes([concrete values])). I originally tried to build trees directly from the upstream test inputs but there were so many edge cases that the test logic was no longer reliable.

A fuzzed types.Header is also parsed, resulting in an RLP "list". As this is the first step in sensitive changes to header encoding, a change-detector test is introduced to lock in backwards compatibility even though no changes are made yet.

[ARR4N]

Closing as superseded by #89.