refactor ZktrieState [dup #903]

[noel2004]

This PR duplicated the target of #903 with another approach:

We consider:

1. A CircuitInputBuilder object should not be reused for building more witness block after it is used inside block_traces_to_witness_block_with_updated_state. as the result, we can updated the ZktrieState memeber in it into the zktrie state after the witness block is applied, just like the state/code_db members.
2. We also notice that Witnessgenerator do not need a snapshot about account /storage states since all the information can be read from the underlying database (ZkMemoryDb here) with trivial cost. So ZktrieState also do not need to keep such a snapshot inside it (they have been kept in state db).
3. With refactoring above, and thanks to the lambda nature of trie's storage. ZktrieState now can esaily switch to any state it have been once updated to, and create new ZkTrie object with almost no cost, which is ready for being updated by another witness block.

[lispc]

nothing very bad but i cannot review line by line. can be merged first.

[noel2004]

Have run mock proving on 40 batches (>200 chunks) from replayed alpha testnet, so far so good