Use less BSS storage space for the rendering and node partitions.

BUG=269765

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

git-svn-id: svn://svn.chromium.org/blink/trunk@157291 bbb929c8-8fbe-4397-9dbb-9b2b20218538
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
Use css-device-adapt constraining for legacy viewport tags.

This CL is trying to take the part of Kenneth's CL [1] that is about using
the constraining procedure from the CSS Device Adaptation spec for legacy
meta tags, as well as for @viewport descriptors, to better match the
specification. Descriptors translated from meta tags are not cascaded with
@viewport rules but are only applied if @viewport from author style is not
present. See thread [2] on www-style.

ViewportArguments::resolve had different modes for resolving viewport
descriptors depending on the source. This CL translates legacy meta viewport
tags into descriptor values as specified by the css-device-adapt spec, but
they are not cascaded together as currently spec'ed. The prioritization is
still the same, overwriting descriptors from lower priority sources.

XHTML MP viewport is implemented through UA styles using @viewport.

[1] https://codereview.chromium.org/19555002/
[2] http://lists.w3.org/Archives/Public/www-style/2012May/0371.html

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

git-svn-id: svn://svn.chromium.org/blink/trunk@157293 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Remove deprecated markersForNode(Node* node)

DocumentMarkerController::markersForNode(Node* node) has been marked as
deprecated in favor of markersFor(Node*, MarkerTypes = AllMarkers()).

WebKit changeset: http://trac.webkit.org/changeset/155095

BUG=

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

git-svn-id: svn://svn.chromium.org/blink/trunk@157294 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Gardening: added one line test expectation for permanently crasing test.

BUG=285703
TBR=

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

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