Speed up commit operations' handling of Merkle tree and contracts map storage

[miloszm]

Summary

Currently, commit operations, esp. commit write, although with regard to memory and bytecodes they behave O(1), which solved more than 95% of our performance problems, yet they are still O(N) with regard to the Merkle tree and contracts map (N is the number of contracts deployed). This means that although the speed of these ops has been dramatically improved, it is still to some extent dependent on N and with very large N can become a problem. This issue is about striving towards O(1) also with regard to Merkle tree and the contracts map (objects which are currently stored in a file named "index"), so summarily they can be called "index".

Possible solution design or implementation

Similarly to memory/bytecodes fix, implement a delta based solution for both Merkle tree and contracts map (the index). This means that the commit will carry around only this delta rather than the entire index, like it is now. Delta will be small and its cloning, copying, de/serializing will be O(1) rather than O(N). At finalisation the deltas will be merged into the main objects and disappear. By main objects it is meant the main Merkle tree and main contracts map, respectively.