Accomodate and document unusual cases in which it is necessary to remove views when clearing backing stores.
ASDK layout and display calls don't depend on UIView in any way, so this
will achieve the necessary behavior of the render range while eliminating significant
UIView-specific overhead from heirarchy manipulation.
There is an unsolved issue with this optimization that may cause crashes
in certain cases. Reverting until it's properly resolved. It doesn't
appear to be possible to cause the issue in the test apps used to develop it.
This reverts commit 3f982b5c9a7e4a557c102268f11f71b58085ffef.
This applies primarily when beginUpdates / endUpdates is not used.
Due to user interaction-driven edits, like reloads or adding content
at the bottom, sometimes this is unavoidable in app design and thus
critical.
I have a diff in flight to make ASDataController / ASRangeController
robust against very aggressive thrash testing, which will be added
both to the unit test suite and this new example project.
This brings back the concept of a window store for nodes that are in the working range (reverting #127). It turns out that due to the system architecture if there are nodes who fetch remote content (e.g. `ASNetworkImageNode`), calls to `-display` will occur before fetching has been completed. The next chance the nodes have to decode and display content is then when they are actually on the screen, thus defeating the purpose of a working range.
With the reintroduction of the working range window, nodes are "stored" in the window and when content is finished being fetched, CA triggers `-display` since they are part of a view hierarchy.
This can be tested in the Kittens project by insuring that before `ASRangeController` adds a node to [a visible view](https://github.com/facebook/AsyncDisplayKit/blob/master/AsyncDisplayKit/Details/ASRangeController.mm#L57) that the image node (with remote content) has set its layer's contents.
