Make ResultIteration safe for use after mutation (option 2)

[dnephin]

This is another option for making the code behave correctly in the scenario described in #85 (other option in #86, #88).

This uses the Txn.Clone added in hashicorp/go-immutable-radix#26 to clone the mutated index before using it in the iterator. From my reading of that PR this use case matches the one it was intended to solve. We need a read-only copy of the yet-to-be-committed tree.

This ensures that the iteration is safe, even if modifications are being made during the iteration. However I believe it does come at the cost of some additional allocations. Once Txn.Clone is called, any further modifications will require creating new nodes rather then re-using the existing modified ones.

TODO:

• document the expect results of using a ResultIterator in a write transaction

Closes #85
Closes #86
Closes #88

[dnephin]

Without this code change, this test would panic here on iter.Next() the second iteration.

[banks]

Code LGTM.

My feeling is that we could be even more super explicit on all the entry points that people querying data are likely to look at (Get mainly but see inline) to make sure they are clear about what consistency is being provided for mutations-while-iterating. See inline comments although there may be other API methods we should add a reference note to that were'nt in your original diff like GetReverse, LowerBound etc.

Approving though as this change seems good to me regardless.