[tree-table] Refactor tree-table, make data structures private

[pzuraq]

Refactors the tree-table component to use private internal data
structures instead of the semi-public LinkedListTree. Replaces the
LinkedListTree with a simpler CollapseTree which should be much cheaper
to build and operate in general.

The new data structure automatically wraps a much simpler POJO structure
that should be passed into TreeTable. It will respond to changes in the
underlying data structure, so if the user updates the POJO everything
will update accordingly.

[visopsys]

This is an interesting data structure. Some question I want to check if my understanding is correct:

1. When you collapse a node, you change the node's length. The parent offset list needs to be updated. If the parent has N children, this will be an O(N) operation. Does this mean we will have O(N) operation for collapsing/expanding?

2. objectAt is a function that calls closestLessThan which is an O(logN) operation. Does this mean dragging a scroller quickly will require O(NlogN) operation?

This might not be a big issue until the table hits 100k rows. If the API is better, we can adopt this over LinkedListTree

[pzuraq]

1. This is true, but will be paid only once during an operation which is relatively uncommon (collapsing/uncollapsing is a user driven event). This is better than the current situation, which is O(N) on every scroll potentially - in the good case it's fine, but in the bad case it's really very bad.
2. It will actually be O(M logN) where M is the number of rendered items (VC will not render every intermediate item, even on fast scrolls. It's gated to 1 update per frame). This is generally very small, ~20-50, so logN dominates here and it's still very fast. We can also further optimize this with a "pointer" like strategy - store the location of the last visited node, and traverse up then back down the tree as necessary. That would reduce the time to being similar to the linked list strategy, while still saving on memory.

The main advantage to this strategy besides autowrapping is reducing the number of allocations by an order of magnitude. We generally have trees which are pretty flat, and leveraging this can reduce the number of allocations to a point where it's almost unnoticeable. Let's say you have a tree with 100 children per parent. At 3 levels deep, that would be 1,000,000 rows. Creating a node per actual, real value-node takes a huge amount of time, and costs a massive amount of memory. By comparison, this tree would generate 10,000 rows, and can be done almost instantaneously on a decently powerful machine.

Denser trees will likely not benefit nearly as much from this strategy, but it also shouldn't hurt them. O(M logN) is still very fast, and we can optimize it further if needed.

[visopsys]

Does this create memleak when Node is no longer used?

[pzuraq]

Observers are instance state and will be garbage collected along with the instance, so long as there are no other references to the instance.

[visopsys]

:+1

Overall looks good. Only one comment regarding the observer.