Make compositing updates 30.7% faster for calculator

This CL makes the compositing updates for the Polymer calculator sample app
30.7% faster by adding a tree-ordered tree walk before computing compositing
requirements.

Previously, we computed the absolute rects for RenderLayers during a
paint-ordered tree walk in computeCompositingRequirements. However, that's
inefficient for three reasons:

1) Most of the time is spent maintaining the RenderGeometryMap, but the
   RenderGeometryMap is optimized for tree-ordered tree walks. If the
   paint-order walk and the tree-order walk were different, we would thrash the
   geometry map.

2) The dirty bits for the absolute rects need to propagate down the tree-order,
   but when walking in paint-order, we didn't have a good way to propagate the
   bits to the tree-order decendants. Instead, we would set update type to
   "force" for the rest of the siblings in the paint-order walk, which is both
   inefficient and incorrect.

3) Finally, this change lets us move the RenderGeometryMap out of
   computeCompositingRequirements entirely, which means we don't need to
   maintain the map as we visit every RenderLayer in the system. Intead, we
   need to maintain the map only for the RenderLayers that we visit in the
   tree-ordered walk, which is pruned by dirty bits.

Now that we have this tree-ordered phase, we can move a bunch of other
computation of tree-ordered data to this phase. Currently we compute that data
during the paint-ordered walks by walking the tree excessively. However, that
works is reserved for a future CL.

R=ojan@chromium.org

Review URL: https://codereview.chromium.org/213773002

git-svn-id: svn://svn.chromium.org/blink/trunk@170141 bbb929c8-8fbe-4397-9dbb-9b2b20218538