Majorly Improve automaticallyAdjustsContentOffset

[Adlai-Holler]

• Only do it for non-animated updates. For animated updates, as I mention in the comments, we can't synchronize with table view's update animation and you see an ugly wave.
  • This is breaking API but we need to do it. No user would ever prefer to see this effect.
• Switch our tracking system to be much simpler and to account for section headers/footers/etc.
• Add a unit test for content offset adjusting

Old system:

Update about to start
Save first visible index path
Update inserted rows
Sum up all the nodes' calculatedSize.height
Update deleted rows
Subtract all the nodes' calculatedSize.height
Update about to end
Find the row at the saved index path (!!! may not be correct)
Add the summed-up value to contentOffset.y

New system:

Update about to start
Save the first visible cell node and its y-offset from the top of viewport.
Update about to end
Find the index path for that cell node, and scroll so that its y-offset is what it was before

This removes a ton of logic where we sum up cellNode.calculatedSize and makes sure we handle things like section headers/footers etc.

I also removed some now-unused arguments from ASDataControllerDelegate and ASRangeControllerDelegate.

Resolves #2908

[Adlai-Holler]

All this can be removed because these methods are required i.e. enforced by compiler. Sorry @nguyenhuy if this requires a rebase but it should be simple if so!

[nguyenhuy]

I also deleted this in #3017. I will rebase with joy if necessary!

[nguyenhuy]

@Adlai-Holler Love it! 1 less thing to handle in #3017. Thanks a ton!

[nguyenhuy]

It's great that this edge case is handled.

Non-blocking feedback: I'm wondering if we should store 1 or maybe even 2 more nodes? That way we would rarely give up because all of the anchor nodes were gone. The last visible node and the one in the middle are good candidates for this purpose.

[Adlai-Holler]

Good call! For the time being, let's leave it as-is to reduce complexity since cases where they delete the anchor row will be somewhat rare, and I have a suspicion that not many people are using this flag.

[nguyenhuy]

I guess these lines are deleted based on the assumption that edits are always done in batches and so offset adjustment can be solely done in -rangeController: didEndUpdatesAnimated:completion:?

I honestly think we should embrace this "always in batches" strategy to the point that there should be only one delegate method -rangeController:didUpdateWithChangeSet:. It will allow us to greatly simplify ASCollectionView and ASTableView. Currently those classes need many internal states to deal with the possibility that updates can be done separately.

[nguyenhuy]

I also deleted this in #3017. I will rebase with joy if necessary!