make cachekv store thread-safe again

[yihuang]

In #13881 we identified and fixed a deadlock issue by removing a lock on btree which makes cachekv iterations not thread-safe anymore.
It'd be good if we can support the concurrent use cases again with simple solutions and don't add much overhead for non-concurrent use cases.
Previously there are two issues regarding thread-safty:

• iterator need to hold the read lock of sorted cache, which blocks creation of new iterators which may need to insert new dirty items into the sorted cache.
• iterator reference store.deleted directly without holding locks.

The first issue can be solved with copy-on-write feature of tidwall/btree, each iterator just make a isolated snapshot of the sorted cache, don't block the operations on the main one.
For the second issue, I don't understand the purpose of deleted field, we should check the nil value for deleted keys. But I think this change will be a behavior change and breaking.