Design Background
When flowing content inside varying size fragmentainers (such as regions) the CSS3
Break spec states the sizes are resolved using the fragmentainer where content is
currently flown. For example, imagine there's a region with width 100px and one with
width 200px. If we flow a paragraph with width: 100% in the regions, the fragment
inside the first region will have a width of 100px and the one in the second region
200px.

To achieve this effect in Blink there's a data structure called RenderBoxRegionInfo
that holds the size delta for each box in each region. These structures are placed
in a map<RenderBox, RenderBoxRegionInfo> inside the RenderRegions. To compute the
width of a box it's necessary to look at the containing block width. This is why you
need the region for both the box and the containing block. The important thing to note
is they are not the same for a certain position inside the flow. If the containing
block has a fixed height and the box being flown is inside its overflow, positioned
in a different region, you need to layout the box like it's inside the last region of
the containing block. This is called clamping. If a block has a region range X->Y and
a box appears inside Y+1, by using clamping you resolve the width of the box by using
the size of the containing block inside region Y, not Y+1.

The offsetFromLogialTopOfFirstPage represents the distance from the top of the box to
the top of the RenderFlowThread (or the first region). Using this value it's possible
to get the region you're interested about (because when laying out the flow thread you
know how tall each region is so it's easy to determine the region by looking at the
vertical offset). When passing this parameter from a box to it's containing block you
have to subtract the logicalTop() of the box from the offsetFromLogialTopOfFirstPage
value.

This parameter works more or less like a hot potato. Without the patch I'm proposing
you can only get a valid offsetFromLogicalTopOfFirstPage only for the current block
being laid out (because the getter function uses the LayoutState object). So when you
try to get the available width in a certain region you pass the
offsetFromLogicalTopOfFirstPage for the current block and when computing the widths of
the containing blocks inside that region you adjust that parameter by subtracting the
logicalTop every time you go up one level. The patch allows calling
offsetFromLogicalTopOfFirst page for all the boxes whatever the LayoutState is. It's no
longer necessary to have the hot potato passed around. When you need the
offsetFromLogicalTopOfFirstPage for a box you can get it directly as a function on
RenderBox.

The patch changes the following things:
- exposes offsetFromLogicalTopOfFirstPage() to all the RenderBoxes;
- offsetFromLogicalTopOfFirstPage() is now safe to call from any box inside a flow
  thread, not only the currently being laid out;
- removes the offsetFromLogicalTopOfFirstPage parameter from all the layout functions 
  that didn't actually required it; when the value is necessary, the
  offsetFromLogicalTopOfFirstPage function is called instead;
- RenderFlowThread now handles its own logic for obtaining the offset from logical top
  of the first region for a box, based on the layout states pushed on RenderView; it
  provides a better caching mechanism that can be used for all the ancestor containing
  blocks of the current box being laid out.

The RenderBoxRegionInfo structures are cached only based on the box and the region. This
means that passing around a value for offsetFromLogicalTopOfFirstPage different in some
cases than others was risky. If there is a possibility of having a different box info
result for a different offset then the cache is not working correctly.

On the long run it is very likely to have nested fragmentation contexts, all based on
RenderFlowThreads. Moving the pagination state outside the RenderView, on the
RenderFlowThread, may open new opportunities for cleaning up the LayoutState structure.

This change didn't introduce any known regressions in WebKit since it landed and it
exposed an error in the layout code by enabling an assertion in
offsetFromLogicalTopOfFirstPage https://chromiumcodereview.appspot.com/19542002/

R=jchaffraix@chromium.org, ojan@chromium.org, eseidel@chromium.org
BUG=245270

Review URL: https://chromiumcodereview.appspot.com/16278007

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