[Trie] Allow swapping out keccak256 implementation

[faustbrian]

Currently when you use the SecureTrie from the trie package you are automatically getting the keccak256 function from https://github.com/ethereum/js-ethereum-cryptography which is a pure JS implementation of that algorithm. There might be scenarios where you want to swap out that implementation for something more performant like https://github.com/bcoin-org/bcrypto, especially if you have high frequency read and write operations. The implementation for this should be fairly straightforward because it would only concern the Trie, SecureTrie and TrieNode implementations.

-------------------------------------------------------------------------------
Benchmarking: Hashing
-------------------------------------------------------------------------------
Operation                        Per Second       Per Operation
bcrypto                          2,898            345μs
js-ethereum-cryptography         1,828            546μs
-------------------------------------------------------------------------------
Memory
-------------------------------------------------------------------------------
rss=52.7mb heap=17.6mb used=9.6mb ext=1.3mb

Could look something like https://github.com/faustbrian/ethereumjs-monorepo/commit/566c6e714aa6cecf16c65bd6b8f1289625cb937e

[faustbrian]

It does feel a bit awkward how https://github.com/faustbrian/ethereumjs-monorepo/commit/566c6e714aa6cecf16c65bd6b8f1289625cb937e is implemented because instead of using a shared object between all files without requiring constructor parameters the function has to be passed around everywhere where it is used. This is how the library is architected but nevertheless it does feel a bit awkward compared to a shared object that holds implementations of functions that are used throughout the library.

[holgerd77]

A bit in the same spirit as my answer on the other thread: currently we are very much (95%+) focused on getting the breaking releases out of the door, basically the whole month of June will be dedicated to that.

Since the suggestion here would be a non-breaking change I would put a bit aside.