This simulates shard shadowing.
In order to fully correctly replay state changes and get matching state roots, all kinds of state changes need to be applied, including the ones which currently are filtered out. To achieve this I add a compilation feature.
Furthermore, DelayedReceipt{,Indices} state changes have no information about the shard they are coming from, which leads to two issues:
1) If two shards have a `DelayedReceipt` change, they will override one another, and the StateChanges column will contain only one of them.
2) We don't know to which shard to apply these state changes.
The solution is to encode ShardUId in the row key of the StateChanges column for these two kids of state changes.
The other kinds of state changes are matched to shards by their account_ids or receiver_ids.
Combination of these two solutions lets us have a backwards-compatible solution.