Changes tries: support forks

[svyatonik]

Brief overview:

1. previously there has been ChangesTrieRootsStorage::root(block: u64) -> ChangesTrieRoot. Obviously, this won't work with non-instant finality => changed ChangesTrieRootsStorage::root(anchor, block: u64) where 'anchor' is the descendant of the block we're processing in current request (either in building trie or requesting changes)
2. ChangesTrieRootsStorage::root is now implemented as: if block <= last_finalized_block => read trie root of finalized block, else traverse from anchor back to the block with given number. This won't work if someone will query key changes from abandoned fork (i.e. fork that has been forked before best finalized block), but not sure if anyone will ever want this query + this increases fn root performance significantly.
3. since we now need parent block hash when building changes trie for the block, ext_storage_changes_root is changed to accept two parameters (parent_hash + parent_num) instead of single one (block)

Out-of-scope question: are we going to support Hasher that has Hasher::Out not compatible with Header::Hash (i.e. Hasher::Out is H512 and Header::Hash is H256)? There are some conversions of Hasher::Out <-> Header::Hash across the code (I've also introduced couple in this PR, isolated in convert_hash functions) and they looks different every time - sometimes they're checking other' hash length before copying, sometimes - not (=> panic if lengths are different). Probably there's a way to bind these types at compilation time? Or probably better to introduce some global convert_hash utility function?

[rphmeier]

are we going to support Hasher that has Hasher::Out not compatible with Header::Hash (i.e. Hasher::Out is H512 and Header::Hash is H256...)

I would say for now, this is not going to happen. It's meant to be the hash function that the header hash is computed with. We should add a type-level constraint there if possible.

[rphmeier]

Needs merge, generally looks good. Ideally would see a deduplication of convert_hash function and perhaps an optimized lookup path for ancestry traversal when anchor is in the canonical chain.

[gavofyork]

My merge didn't work - will need a little more work I think @svyatonik