Trie debug tooling

[BGluth]

I think it's probably a good idea to get this tooling back into main as the LoC count is starting to get pretty high.

There are two tools in this PR:

• Trie diffing --> Attempts to find divergences between two tries.
• Trie path querying --> Gives detailed information on the nodes hit when searching for a key in a trie.

I've only finished 1/2 of what I originally was planning for the diff tooling (I haven't implemented bottom-up diffs), but top-down diffs were enough for me to figure out the issue that I built it for, so I'll come back and finish bottom-up later on. The query logic I think is done. The way this information is printed out (the Display impls) could be a bit better, but this is something that I'll clean up in a separate PR down the road.

Both of these tools are placed behind the new feature flag trie_debug.

[Nashtare]

Mostly nitpicky comments, some are purely for my (and possibly others) understanding when diving into the codebase. I'll probably do another pass later.

[Nashtare]

The naming is a bit hard to decrypt, without reading the comment (which won't show up in rustdoc). Though I don't have a better suggestion in mind.

[BGluth]

I'll come up with something better...

[BGluth]

Potentially a bit better?

/// Get the key piece from the given node if applicable.
///
/// Note that there is no specific [`Nibble`] associated with a branch like
/// there is with [Extension][`Node::Extension`] and [Leaf][`Node::Leaf`] nodes,
/// and the only way to get the nibble "associated" with branches is to look at
/// the next Nibble in the current key as we traverse down it.
pub(super) fn get_key_piece_from_node_pulling_from_key_for_branches<T: PartialTrie>(
    n: &Node<T>,
    curr_key: &Nibbles,
) -> Nibbles {
    ...
}

/// Get the key piece from the given node if applicable. Note that
/// [branch][`Node::Branch`]s have no [`Nibble`] directly associated with them.
pub(super) fn get_key_piece_from_node<T: PartialTrie>(n: &Node<T>) -> Nibbles {
    ...
}

[Nashtare]

So yes, it's easier to understand, but now I think we've hit another issue 😆 I think we usually should try to not have function names with more than 5/6 words max. But let's go with it, we can always do a pass on renaming long functions into clearer names later on.

[Nashtare]

Thanks! Overall looks good to me, we may do some light cleanup / refactoring later on, but that's already pretty cool to get this into main 😃