Please define how the various box tree fixups interact #1355

There are now multiple CSS specs that define various computed display and box tree fixups. For example (this is probably not an exhaustive list):

• https://www.w3.org/TR/CSS21/visuren.html#anonymous-block-level defines a fixup that happens if an inline box contains a block box; note that this does NOT create any anonymous boxes other than ones inlines create anyway.
• Various blockification fixups for flex, grid, being floated, positioned
• Fixups for mismatched writing-mode.
• Fixups for ruby as defined at https://drafts.csswg.org/css-ruby/#box-fixup
• Fixups for tables as defined at https://www.w3.org/TR/CSS21/tables.html#anonymous-boxes

The ordering of this stuff needs to be defined. And yes, it matters, apparently. Some examples of it mattering:

1. Gecko code has comments about how the ruby bits have to come after the grid bits, for certain tests to pass.
2. If you have a block-inside-inline all inside a ruby container, what happens? The ruby things say they happen "after any intermediary anonymous-box fixup", but it's not clear to me whether the anonymous-block thing above counts as "intermediary anonymous-box fixup". If it does, then it seems like the output should be three inline-block boxes, the first containing the first inline, the second being the inlinized block, and the third containing the third inline. If it doesn't, then the output should be a ruby container with a block child.

For the second item, I tested what some UAs do. Testcase:

  <ruby>
    Start
    <span style="border: 10px solid green">
      <div style="background: yellow">Text</div>
    </span>
    End
  </ruby>

Observed behavior: Chrome, Safari, and Edge don't inlinize as far as I can tell, no matter whether the <span> is there. Firefox does inlinize, but does that in some sort of deep traversal and before doing the block-inside-inline fixup, so ends up with a green box around "Text".