refactor: Separate database integration from trie into its own crate

[RomanHodulak]

Closes #8514

[mattsse]

I'm unequipped to review these code changes and there are quite a few @rkrasiuk

my original idea was to extract the types instead (especially trieupdates) and then work towards making them not dependent on the db deps.

but this approach also works, but I'm not sure about these changes, because using wrapper types to implement a trait is not ideal.

I assume it would be more useful to have
trie-types and trie
wdyt @rkrasiuk

[mattsse]

perhaps we kick this off by extracting these:

https://github.com/paradigmxyz/reth/tree/01fd9b3c76705e582cea17774f269fe4a78d8af3/crates/primitives/src/trie

to trie-types instead and then try to move more stuff from reth-trie there?

[RomanHodulak]

Hey @mattsse, thank you for reviewing my PR so swiftly.

So far I've been thinking that crates:

• reth-trie - contains types and behavior of the Trie domain, but does not depend on a database, the concept of database does not really exist there. Should I rename it to reth-trie-types?
• reth-trie-db - is a projection of the reth-trie into the database, but does not define any concepts of the Trie domain. It implements the traits defined by the Trie domain using reth_database. There might be other implementations than the reth_database. that's why the reth-trie-db shouldn't contain domain behavior or types, otherwise that would lead to duplication of knowledge.

I haven't looked into the primitives crate yet, so that's where I'll go next. It does make sense to pull the trie module out of that crate and put it into the reth-trie crate.

[RomanHodulak]

Superseded by #9282