Working range window

[rnystrom]

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 that the image node (with remote content) has set its layer's contents.

[secretiverhyme]

Let's move the

  [node recursivelySetDisplaySuspended:NO];

call out of the range controller and into ASRangeHandlerRender, then land this!

[rnystrom]

Also making a note from @appleguy that thrashing a UIWindow like this will likely incur some wasted processing on the main thread. Something we should be aware of and fix soon.

[secretiverhyme]

Yup — the hierarchy manipulation thrash is specifically why we wanted to kill the rendering-window hack. We're going to have to either convert the render range to "continuously re-display everything as needed" (matching the rendering window behaviour) or set up something like the state machine described in #315, so nodes can know whether they're supposed to render themselves once preload data arrives.

[secretiverhyme]

just to be absolutely safe, can we add an ASDisplayNodeAssertMainThread() here?

[secretiverhyme]

Two tiny nits, then we're good to merge. =]

[rnystrom]

Nits have been picked!