[MARF] Investigate sparse trie representations

[jcnelson]

@kantai and myself suspect that the bulk of redundant data in a MARF index comes from one of a handful of places:

• When performing a copy-on-write to produce a new trie, most of the nodes on the trie path will not change very much between two subsequent tries.

• When performing a copy-on-write, most trie backpointers will point to the same nodes they did when they were created

• A substantial number of leaves will have the (same) empty hash, since their keys are unmapped

• We don't use varint encodings for integers, even though most integers fit into fewer than four bytes

I need to figure out how much of a potential space savings we can get by addressing some or all of the above.

[jcnelson]

Discoveries so far:

• Not storing the back_block field in a TriePtr for non-backptr nodes saves 10-15% of space in tests. This value is always 0 for non-backptr nodes

• Not storing the intermediate hashes of each node (which are only needed on Merkle proof construction) saves about 5% of space in tests. These can be regenerated on-the-fly.