Allow NG objects inside force-legacy layout subtrees.

We usually refrain from creating NG objects inside a force-legacy
layout subtree (with the LegacyLayout enum). However, in some cases we
might still want to insist on creating NG objects in such a subtree,
e.g. if the box type has no legacy layout implementation (which is the
case for e.g. MathML).

This resolves bug 943574 - albeit as WontFix, since that bug asserts
that we shouldn't have NG objects inside legacy subtrees.

No behavior changes intended; this is just a preparatory CL for MathML
to work inside legacy subtrees.

Bug: 943574
Change-Id: Ic3d99c0f072f6bd5b849280ad29b4f4aaedde99d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2400501Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Cr-Commit-Position: refs/heads/master@{#805754}

third_party/blink/renderer/core/layout/layout_object_child_list.cc

@@ -242,12 +242,8 @@ void LayoutObjectChildList::InsertChildNode(LayoutObject* owner,
   if (new_child->WasNotifiedOfSubtreeChange())
     owner->NotifyAncestorsOfSubtreeChange();
 
-  if (owner->ForceLegacyLayout()) {
+  if (owner->ForceLegacyLayout() && !new_child->IsLayoutNGObject())
     new_child->SetForceLegacyLayout();
-    // TODO(crbug.com/943574): This would be a great place to DCHECK that the
-    // child isn't an NG object, but there are unfortunately cases where this
-    // actually happens.
-  }
 
   new_child->SetNeedsLayoutAndIntrinsicWidthsRecalc(
       layout_invalidation_reason::kAddedToLayout);