LazyVec/Set/Map for storage

[tzemanovic]

Depends on #166 and #167.

For our VPs and txs env, we should implement LazyVec, LazySet and LazyMap. The purpose of these is to replicate the data structure and API for Vec, HashSet and HashMap, but instead of directly serializing these to a single storage key-val, each entry in these collections would be backed by a storage sub-key to allow using these effectively in tx/VPs, avoiding (potentially unbounded) iterations and also making VP validation of such data easier (the protocol provides the changed storage sub-keys, instead of the VP having to find the diff between pre and post state inside the collections.

For each collection, we should persist the length at another sub-key and for:

• LazyVec, the index of each element is the storage sub-key, the value is the value
• LazySet, the hash of each element is the storage sub-key, the value is the unhashed element
• LazyMap, the hash of each key is the storage sub-key, the value is a tuple of unhashed key and the value

e.g. a vec of elements [1, 2, 5] would be stored in sub-keys:

• /len = 3
• /data/{0} = 1
• /data/{1} = 2
• /data/{2} = 5

a hash set of elements [2, 5, 8]:

• /data/{hash(2)} = 2
• /data/{hash(5)} = 5
• /data/{hash(8)} = 8

a hash map of elements [("key_a", 1), ("key_b", 7), ("key_c", 2)]:

• /data/{hash("key_a")} = ("key_a", 1)
• /data/{hash("key_b")} = ("key_b", 7)
• /data/{hash("key_c")} = ("key_c", 2)