CURATOR-33 recursive TreeCache recipe

I know this comment comes form path and node cache, but I find it very unhelpful. I think it would be more clear to note that a sequence of updates to any two nodes may be delivered in any sequence by the cache. 

But, it also seems like we should be able to offer a much stronger consistency guarantee. Watches are guaranteed to fire in order from the ZK protocol level, and therefore we should be able to give consistent delivery of e.g. a recursive delete bottom up, tree creation top-down, etc. TreeCache is potentially in a much better position to do this since it need not segment the listener for each path into its own single threaded executor. 

The only major caveat I see here is on a disconnect/reconnect case where we have to re-read the tree, but the events could still be synthesized in correct tree order for add/remove.