[LayoutNG] A different approach to multi-col.

[LayoutNG] A different approach to multi-col.

DO NOT SUBMIT

This is just a prototype patch to see if this approach to multi-col
would work.

Instead of emmbedding the knowledge of how to perform multi-col layout
inside of block flow, this creates a new layout algorithm:
NGMutiColumnLayoutAlgorithm.

This essentially only ever performs layout on one child - itself. It
will initially perform layout on itself using block-flow to determine
where all the break opportunities are.

In the second pass it would create constraint spaces, with appropriate
fragmentation lines, to create anonymous fragments for each of the
columns.

This is be biggest difference from the block-flow approach, it
introduces the concept of anonymous wrapping fragments. I think we'll
need this anyway for line layout. I don't this we have any reason to
shy-away from them as they are relatively small.

Once it fragments itself it can place the columns in the appropriate
position, and return its fragment.

Other things we'll need (that aren't in this patch):
 - Anonymous flag on fragments; we'll need this to communicate to the
   paint code that it should just paint the children.

 - Muti-col estimation flag on constraint space; we'll need this to
   communicate to child multi-cols that we are in the estimation phase,
   and the children shouldn't fragment during this step.

 - Anonymous wrapper flag on constraint space; we'll need this to have a
   few small switches inside block-flow to not include
   border-and-padding etc.

 - Multi-col spanner box list on fragment; we'll need this to bubble up
   spanner input nodes to that the fragmentainer (conceptually the
   NGMutiColumnLayoutAlgorithm) here to perform layout at the top level.

This also fixes a few things which were missing in the previous
implementation:
 - Removes side effect of "Finished" on the NGBlockNode. This allows us
   to properly cache the output, and perform re-layouts without
   constructing a new NGBlockNode.

BUG=
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_layout_ng

[ikilpatrick, 2017-02-14 17:48:28]

Description was changed from

==========
[LayoutNG] A different approach to multi-col.

This is just a prototype patch to see if this approach to multi-col
would work.

Instead of emmbedding the knowledge of how to perform multi-col layout
inside of block flow, this creates a new layout algorithm:
NGMutiColumnLayoutAlgorithm.

This essentially only ever performs layout on one child - itself. It
will initially perform layout on itself using block-flow to determine
where all the break opportunities are.

In the second pass it would create constraint spaces, with appropriate
fragmentation lines, to create anonymous fragments for each of the
columns.

This is be biggest difference from the block-flow approach, it
introduces the concept of anonymous wrapping fragments. I think we'll
need this anyway for line layout. I don't this we have any reason to
shy-away from them as they are relatively small.

Once it fragments itself it can place the columns in the appropriate
position, and return its fragment.

Other things we'll need (that aren't in this patch):
 - Anonymous flag on fragments; we'll need this to communicate to the
   paint code that it should just paint the children.

 - Muti-col estimation flag on constraint space; we'll need this to
   communicate to child multi-cols that we are in the estimation phase,
   and the children shouldn't fragment during this step.

 - Anonymous wrapper flag on constraint space; we'll need this to have a
   few small switches inside block-flow to not include
   border-and-padding etc.

 - Multi-col spanner box list on fragment; we'll need this to bubble up
   spanner input nodes to that the fragmentainer (conceptually the
   NGMutiColumnLayoutAlgorithm) here to perform layout at the top level.

This also fixes a few things which were missing in the previous
implementation:
 - Removes side effect of "Finished" on the NGBlockNode. This allows us
   to properly cache the output, and perform re-layouts without
   constructing a new NGBlockNode.

BUG=
==========

to

==========
[LayoutNG] A different approach to multi-col.

DO NOT SUBMIT

This is just a prototype patch to see if this approach to multi-col
would work.

Instead of emmbedding the knowledge of how to perform multi-col layout
inside of block flow, this creates a new layout algorithm:
NGMutiColumnLayoutAlgorithm.

This essentially only ever performs layout on one child - itself. It
will initially perform layout on itself using block-flow to determine
where all the break opportunities are.

In the second pass it would create constraint spaces, with appropriate
fragmentation lines, to create anonymous fragments for each of the
columns.

This is be biggest difference from the block-flow approach, it
introduces the concept of anonymous wrapping fragments. I think we'll
need this anyway for line layout. I don't this we have any reason to
shy-away from them as they are relatively small.

Once it fragments itself it can place the columns in the appropriate
position, and return its fragment.

Other things we'll need (that aren't in this patch):
 - Anonymous flag on fragments; we'll need this to communicate to the
   paint code that it should just paint the children.

 - Muti-col estimation flag on constraint space; we'll need this to
   communicate to child multi-cols that we are in the estimation phase,
   and the children shouldn't fragment during this step.

 - Anonymous wrapper flag on constraint space; we'll need this to have a
   few small switches inside block-flow to not include
   border-and-padding etc.

 - Multi-col spanner box list on fragment; we'll need this to bubble up
   spanner input nodes to that the fragmentainer (conceptually the
   NGMutiColumnLayoutAlgorithm) here to perform layout at the top level.

This also fixes a few things which were missing in the previous
implementation:
 - Removes side effect of "Finished" on the NGBlockNode. This allows us
   to properly cache the output, and perform re-layouts without
   constructing a new NGBlockNode.

BUG=
==========

[ikilpatrick, 2017-02-14 17:48:35]

ikilpatrick@chromium.org changed reviewers:
+ mstensho@opera.com

[ikilpatrick, 2017-02-14 17:48:36]

This is obviously not for committing... rather just a "high-level-approach"
review if that makes sense.

I ended up on this path when converting NGBreakToken to being RefCounted. The
ownership was complex, so ended up trying to add in the "child-break-tokens" as
previously discussed, which ended up rethinking how to do multicol somewhat :).

[ikilpatrick, 2017-02-15 17:08:53]

ikilpatrick@chromium.org changed reviewers:
+ glebl@chromium.org

[mstensho (USE GERRIT), 2017-02-15 21:12:23]

OK, probably time for me to stop this nitpicking and comment writing. :)

As for the general approach, I like it!

During my work on the CL back in January that introduced some limited multicol
support, I actually considered creating a dedicated algorithm for multicol, with
something that could easily be called anonymous fragments (for each column box).
I had a feeling that would make it easier to paint column rules, but I wasn't
sure how one would go about doing that in any case. I decided against the extra
algorithm, because back then we had both NGBlockLayoutAlgorithm and
NGInlineLayoutAlgorithm (which would be created for blocks with inline children,
and a multicol container may very well have inline children), and also because
there really was no concept of "anonymous fragments".

So I definitely think you're on the right track here.

https://codereview.chromium.org/2693193002/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc
(left):

https://codereview.chromium.org/2693193002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc:572:
fragmentainer_mapper_->ToVisualOffset(logical_offset);
Is the plan to replace the fragmentainer mapper with something else? It might be
viable to cram all its logic into the column layout algorithm, now that we do
have a dedicated algorithm for multicol.

https://codereview.chromium.org/2693193002/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc
(right):

https://codereview.chromium.org/2693193002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc:400:
break_token_ ? LayoutUnit(0) : border_and_padding_.block_start;
Should use LayoutUnit() instead of LayoutUnit(0), or you end up performing
checks for saturated arithmetics.

https://codereview.chromium.org/2693193002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc:577: ?
content_size_ >= constraint_space_->FragmentainerSpaceAvailable()
All you need is: constraint_space_->HasBlockFragmentation() && content_size_ >=
constraint_space_->FragmentainerSpaceAvailable()

https://codereview.chromium.org/2693193002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc:716:
space_available -= builder_->BfcOffset().value().block_offset;
I don't understand how this is supposed to work. We want to subtract the
distance from the top of the current column to the top of the fragment to
create, but what does BFC offset have to do with it?

https://codereview.chromium.org/2693193002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc:720:
space_builder_->SetFragmentainerSpaceAvailable(LayoutUnit(0));
Just LayoutUnit().

https://codereview.chromium.org/2693193002/diff/1/third_party/WebKit/Source/c...
File
third_party/WebKit/Source/core/layout/ng/ng_multi_column_layout_algorithm.cc
(right):

https://codereview.chromium.org/2693193002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/layout/ng/ng_multi_column_layout_algorithm.cc:61:
adjusted_inline_size + ResolveUsedColumnGap(Style());*/
So this is currently missing, right? We need to be able to increment the inline
offset of each column fragment that we create.

https://codereview.chromium.org/2693193002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/layout/ng/ng_multi_column_layout_algorithm.cc:75:
.SetAvailableSize(
I've been meaning to ask this for some time:

What's the deal with chaining function calls into one statement like this? To me
it looks less readable than:

space_builder_->SetFragmentationType(kFragmentColumn);
space_builder_->SetAvailableSize(NGLogicalSize(...));
...

I mean, I understand that it's useful if you only want a temporary object that
you don't want to name, e.g.:

SomeFunction(NGConstraintSpaceBuilder(constraint_space_).SetFragmentationType(kFragmentColumn).SetAvailableSize(NGLogicalSize(...)));

But for all other uses I think it just looks less readable, in addition to being
less maintainable.

https://codereview.chromium.org/2693193002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/layout/ng/ng_multi_column_layout_algorithm.cc:111:
// so, layout that next across all the columns. :)
I'm against using spanners and smileys in the same sentence. :)

https://codereview.chromium.org/2693193002/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/layout/ng/ng_multi_column_layout_algorithm.h
(right):

https://codereview.chromium.org/2693193002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/layout/ng/ng_multi_column_layout_algorithm.h:26:
class CORE_EXPORT NGMultiColumnLayoutAlgorithm : public NGLayoutAlgorithm {
I think "NGColumnLayoutAlgorithm" could work too.

[ikilpatrick, 2017-02-16 16:48:32]

Thanks for the high level review. :)

Yeah, I talked yesterday with eae&koji and they'll probably need anonymous
fragments for text layout as well to make that sane. They should be really cheap
which is nice.

I'll begin committing this in small patches. I might just leave the
NGColumnLayoutAlgorithm as a stub, or a very simple mode so we can pickk up the
rest of it when we have time.

(e.g. probably the same amount of functionality as before).

https://codereview.chromium.org/2693193002/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc
(left):

https://codereview.chromium.org/2693193002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc:572:
fragmentainer_mapper_->ToVisualOffset(logical_offset);
On 2017/02/15 21:12:22, mstensho wrote:
> Is the plan to replace the fragmentainer mapper with something else? It might
be
> viable to cram all its logic into the column layout algorithm, now that we do
> have a dedicated algorithm for multicol.

Yeah i think most of the logic inside the fragmentainer mapper could just live
inside the column layout algorithm now... the NGColumnLayoutAlgorithm should
just deal with:
1) Performing the initial layout pass & determining fragmentation lines.
2) Performing layout and placement of each column.
3) Performing layout and placement of each spanner. (which bubble up to their
parent NGColumnLayoutAlgorithm).

I think this should be pretty small to live in one class, but happy to split out
if that isn't the case.

https://codereview.chromium.org/2693193002/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc
(right):

https://codereview.chromium.org/2693193002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc:716:
space_available -= builder_->BfcOffset().value().block_offset;
On 2017/02/15 21:12:22, mstensho wrote:
> I don't understand how this is supposed to work. We want to subtract the
> distance from the top of the current column to the top of the fragment to
> create, but what does BFC offset have to do with it?

Ah yeah this is wrong, we need a IsNewFormattingContext check here as well;
basically it will cover this case:

So each column will establish a new (anonymous) block formatting context.
<div id=multicol> <!-- the multi-col element, anon column is new FC -->
  <div id=in-flow-no-new-fc> <!-- "this" - the current layout -->
    <div id=zero-height></div>
    <div id=in-flow-new-fc></div>
  </div>
</div>

"in-flow-no-new-fc" currently doesn't currently know where it is inside its
formatting context; the fragmentation line is with respect to the formatting
context.

When it comes to performing layout upon "in-flow-new-fc" it has to determine the
BFC offset for that child (before that child's layout call) so that it can give
the child the correct fragmentation line with respect to *its* formatting
context.

https://codereview.chromium.org/2693193002/diff/1/third_party/WebKit/Source/c...
File
third_party/WebKit/Source/core/layout/ng/ng_multi_column_layout_algorithm.cc
(right):

https://codereview.chromium.org/2693193002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/layout/ng/ng_multi_column_layout_algorithm.cc:75:
.SetAvailableSize(
On 2017/02/15 21:12:23, mstensho wrote:
> I've been meaning to ask this for some time:
> 
> What's the deal with chaining function calls into one statement like this? To
me
> it looks less readable than:
> 
> space_builder_->SetFragmentationType(kFragmentColumn);
> space_builder_->SetAvailableSize(NGLogicalSize(...));
> ...
> 
> I mean, I understand that it's useful if you only want a temporary object that
> you don't want to name, e.g.:
> 
>
SomeFunction(NGConstraintSpaceBuilder(constraint_space_).SetFragmentationType(kFragmentColumn).SetAvailableSize(NGLogicalSize(...)));
> 
> But for all other uses I think it just looks less readable, in addition to
being
> less maintainable.

I think just that's what all the other builders looked like; I'm fine ripping
this out if others agree in the chat :).

https://codereview.chromium.org/2693193002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/layout/ng/ng_multi_column_layout_algorithm.cc:111:
// so, layout that next across all the columns. :)
On 2017/02/15 21:12:23, mstensho wrote:
> I'm against using spanners and smileys in the same sentence. :)

:)

https://codereview.chromium.org/2693193002/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/layout/ng/ng_multi_column_layout_algorithm.h
(right):

https://codereview.chromium.org/2693193002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/layout/ng/ng_multi_column_layout_algorithm.h:26:
class CORE_EXPORT NGMultiColumnLayoutAlgorithm : public NGLayoutAlgorithm {
On 2017/02/15 21:12:23, mstensho wrote:
> I think "NGColumnLayoutAlgorithm" could work too.

sgtm.

[mstensho (USE GERRIT), 2017-02-16 21:14:48]

https://codereview.chromium.org/2693193002/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc
(right):

https://codereview.chromium.org/2693193002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc:716:
space_available -= builder_->BfcOffset().value().block_offset;
On 2017/02/16 16:48:31, ikilpatrick wrote:
> On 2017/02/15 21:12:22, mstensho wrote:
> > I don't understand how this is supposed to work. We want to subtract the
> > distance from the top of the current column to the top of the fragment to
> > create, but what does BFC offset have to do with it?
> 
> Ah yeah this is wrong, we need a IsNewFormattingContext check here as well;
> basically it will cover this case:
> 
> So each column will establish a new (anonymous) block formatting context.

Not sure if I misunderstand what you mean here, but column boxes don't establish
new block formatting contexts. The container does, but each column doesn't.

https://codereview.chromium.org/2693193002/diff/1/third_party/WebKit/Source/c...
File
third_party/WebKit/Source/core/layout/ng/ng_multi_column_layout_algorithm.cc
(right):

https://codereview.chromium.org/2693193002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/layout/ng/ng_multi_column_layout_algorithm.cc:75:
.SetAvailableSize(
On 2017/02/16 16:48:31, ikilpatrick wrote:
> On 2017/02/15 21:12:23, mstensho wrote:
> > I've been meaning to ask this for some time:
> > 
> > What's the deal with chaining function calls into one statement like this?
To
> me
> > it looks less readable than:
> > 
> > space_builder_->SetFragmentationType(kFragmentColumn);
> > space_builder_->SetAvailableSize(NGLogicalSize(...));
> > ...
> > 
> > I mean, I understand that it's useful if you only want a temporary object
that
> > you don't want to name, e.g.:
> > 
> >
>
SomeFunction(NGConstraintSpaceBuilder(constraint_space_).SetFragmentationType(kFragmentColumn).SetAvailableSize(NGLogicalSize(...)));
> > 
> > But for all other uses I think it just looks less readable, in addition to
> being
> > less maintainable.
> 
> I think just that's what all the other builders looked like; I'm fine ripping
> this out if others agree in the chat :).

Yes, this is a common pattern in this code. I'm just wondering why. :)

[atotic, 2017-02-16 21:34:15]

> > I think just that's what all the other builders looked like; I'm fine
ripping
> > this out if others agree in the chat :).
> 
> Yes, this is a common pattern in this code. I'm just wondering why. :)

Personally I find it useful to:

- avoid naming a temporary object.

- avoid excessive line wraps:
  variable_name_is_really_really_long->LetsMeFitSetsOnASingleLine();

So I would not rip all of them out.

[Gleb Lanbin, 2017-04-03 16:54:55]

https://codereview.chromium.org/2693193002/diff/80001/third_party/WebKit/Sour...
File
third_party/WebKit/Source/core/layout/ng/ng_multi_column_layout_algorithm.cc
(right):

https://codereview.chromium.org/2693193002/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/ng/ng_multi_column_layout_algorithm.cc:105:
RefPtr<NGLayoutResult> layout_result =
this should be declared out of the loop's scope. Otherwise break_token will have
an unpredictable value after layout_result went out of the scope.

[ikilpatrick, 2017-05-14 18:50:31]

Description was changed from

==========
[LayoutNG] A different approach to multi-col.

DO NOT SUBMIT

This is just a prototype patch to see if this approach to multi-col
would work.

Instead of emmbedding the knowledge of how to perform multi-col layout
inside of block flow, this creates a new layout algorithm:
NGMutiColumnLayoutAlgorithm.

This essentially only ever performs layout on one child - itself. It
will initially perform layout on itself using block-flow to determine
where all the break opportunities are.

In the second pass it would create constraint spaces, with appropriate
fragmentation lines, to create anonymous fragments for each of the
columns.

This is be biggest difference from the block-flow approach, it
introduces the concept of anonymous wrapping fragments. I think we'll
need this anyway for line layout. I don't this we have any reason to
shy-away from them as they are relatively small.

Once it fragments itself it can place the columns in the appropriate
position, and return its fragment.

Other things we'll need (that aren't in this patch):
 - Anonymous flag on fragments; we'll need this to communicate to the
   paint code that it should just paint the children.

 - Muti-col estimation flag on constraint space; we'll need this to
   communicate to child multi-cols that we are in the estimation phase,
   and the children shouldn't fragment during this step.

 - Anonymous wrapper flag on constraint space; we'll need this to have a
   few small switches inside block-flow to not include
   border-and-padding etc.

 - Multi-col spanner box list on fragment; we'll need this to bubble up
   spanner input nodes to that the fragmentainer (conceptually the
   NGMutiColumnLayoutAlgorithm) here to perform layout at the top level.

This also fixes a few things which were missing in the previous
implementation:
 - Removes side effect of "Finished" on the NGBlockNode. This allows us
   to properly cache the output, and perform re-layouts without
   constructing a new NGBlockNode.

BUG=
==========

to

==========
[LayoutNG] A different approach to multi-col.

DO NOT SUBMIT

This is just a prototype patch to see if this approach to multi-col
would work.

Instead of emmbedding the knowledge of how to perform multi-col layout
inside of block flow, this creates a new layout algorithm:
NGMutiColumnLayoutAlgorithm.

This essentially only ever performs layout on one child - itself. It
will initially perform layout on itself using block-flow to determine
where all the break opportunities are.

In the second pass it would create constraint spaces, with appropriate
fragmentation lines, to create anonymous fragments for each of the
columns.

This is be biggest difference from the block-flow approach, it
introduces the concept of anonymous wrapping fragments. I think we'll
need this anyway for line layout. I don't this we have any reason to
shy-away from them as they are relatively small.

Once it fragments itself it can place the columns in the appropriate
position, and return its fragment.

Other things we'll need (that aren't in this patch):
 - Anonymous flag on fragments; we'll need this to communicate to the
   paint code that it should just paint the children.

 - Muti-col estimation flag on constraint space; we'll need this to
   communicate to child multi-cols that we are in the estimation phase,
   and the children shouldn't fragment during this step.

 - Anonymous wrapper flag on constraint space; we'll need this to have a
   few small switches inside block-flow to not include
   border-and-padding etc.

 - Multi-col spanner box list on fragment; we'll need this to bubble up
   spanner input nodes to that the fragmentainer (conceptually the
   NGMutiColumnLayoutAlgorithm) here to perform layout at the top level.

This also fixes a few things which were missing in the previous
implementation:
 - Removes side effect of "Finished" on the NGBlockNode. This allows us
   to properly cache the output, and perform re-layouts without
   constructing a new NGBlockNode.

BUG=
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_layout_ng
==========

[mstensho (USE GERRIT), 2017-06-13 12:05:16]

Anything left here?

[ikilpatrick, 2017-06-20 23:59:51]

On 2017/06/13 12:05:16, mstensho wrote:
> Anything left here?

There is, but nothing useful in this patch :) - closing.

[ikilpatrick, 2017-06-21 00:00:02]

Description was changed from

==========
[LayoutNG] A different approach to multi-col.

DO NOT SUBMIT

This is just a prototype patch to see if this approach to multi-col
would work.

Instead of emmbedding the knowledge of how to perform multi-col layout
inside of block flow, this creates a new layout algorithm:
NGMutiColumnLayoutAlgorithm.

This essentially only ever performs layout on one child - itself. It
will initially perform layout on itself using block-flow to determine
where all the break opportunities are.

In the second pass it would create constraint spaces, with appropriate
fragmentation lines, to create anonymous fragments for each of the
columns.

This is be biggest difference from the block-flow approach, it
introduces the concept of anonymous wrapping fragments. I think we'll
need this anyway for line layout. I don't this we have any reason to
shy-away from them as they are relatively small.

Once it fragments itself it can place the columns in the appropriate
position, and return its fragment.

Other things we'll need (that aren't in this patch):
 - Anonymous flag on fragments; we'll need this to communicate to the
   paint code that it should just paint the children.

 - Muti-col estimation flag on constraint space; we'll need this to
   communicate to child multi-cols that we are in the estimation phase,
   and the children shouldn't fragment during this step.

 - Anonymous wrapper flag on constraint space; we'll need this to have a
   few small switches inside block-flow to not include
   border-and-padding etc.

 - Multi-col spanner box list on fragment; we'll need this to bubble up
   spanner input nodes to that the fragmentainer (conceptually the
   NGMutiColumnLayoutAlgorithm) here to perform layout at the top level.

This also fixes a few things which were missing in the previous
implementation:
 - Removes side effect of "Finished" on the NGBlockNode. This allows us
   to properly cache the output, and perform re-layouts without
   constructing a new NGBlockNode.

BUG=
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_layout_ng
==========

to

==========
[LayoutNG] A different approach to multi-col.

DO NOT SUBMIT

This is just a prototype patch to see if this approach to multi-col
would work.

Instead of emmbedding the knowledge of how to perform multi-col layout
inside of block flow, this creates a new layout algorithm:
NGMutiColumnLayoutAlgorithm.

This essentially only ever performs layout on one child - itself. It
will initially perform layout on itself using block-flow to determine
where all the break opportunities are.

In the second pass it would create constraint spaces, with appropriate
fragmentation lines, to create anonymous fragments for each of the
columns.

This is be biggest difference from the block-flow approach, it
introduces the concept of anonymous wrapping fragments. I think we'll
need this anyway for line layout. I don't this we have any reason to
shy-away from them as they are relatively small.

Once it fragments itself it can place the columns in the appropriate
position, and return its fragment.

Other things we'll need (that aren't in this patch):
 - Anonymous flag on fragments; we'll need this to communicate to the
   paint code that it should just paint the children.

 - Muti-col estimation flag on constraint space; we'll need this to
   communicate to child multi-cols that we are in the estimation phase,
   and the children shouldn't fragment during this step.

 - Anonymous wrapper flag on constraint space; we'll need this to have a
   few small switches inside block-flow to not include
   border-and-padding etc.

 - Multi-col spanner box list on fragment; we'll need this to bubble up
   spanner input nodes to that the fragmentainer (conceptually the
   NGMutiColumnLayoutAlgorithm) here to perform layout at the top level.

This also fixes a few things which were missing in the previous
implementation:
 - Removes side effect of "Finished" on the NGBlockNode. This allows us
   to properly cache the output, and perform re-layouts without
   constructing a new NGBlockNode.

BUG=
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_layout_ng
==========