[css-grid] Add additional example when to re-run column sizing based on rows.

[bfgeek]

We have multiple issues (5-6) in our bug tracker where people are expecting the grid sizing algorithm to re-run based on an update size of the rows. E.g.
https://bugs.chromium.org/p/chromium/issues/detail?id=849233
https://bugs.chromium.org/p/chromium/issues/detail?id=1150080
(there are lots more but all more of less have the same structure).

We added a couple of .tentative.html tests based on this:
http://wpt.live/css/css-grid/grid-items/grid-item-inline-contribution-001.html
http://wpt.live/css/css-grid/grid-items/grid-item-inline-contribution-002.tentative.html
http://wpt.live/css/css-grid/grid-items/grid-item-inline-contribution-003.tentative.html

(001 doesn't fall into the "re-run" category but we noticed implementations were sometimes resolving against the grid height - not the row height).

We are 90% sure this is desired by the specification, e.g.
https://drafts.csswg.org/css-grid-2/#algo-overview

 Then, if the min-content contribution of any grid item has changed based on the row sizes and alignment calculated in step 2, re-resolve the sizes of the grid columns with the new min-content and max-content contributions (once only).

Both 002/003 have a grid-item which will have initially an indefinite height, then definite (in the 2nd pass) causing the min-content size to change.

It'd be good if this was explicitly called out in the note listing example for when this occurs.

[fantasai]

@bfgeek Yes, as far as we can tell, these tests are correct and demonstrate exactly why the grid algorithm cycles through the row and column track sizing steps twice. Please mark them as non-tentative! We're also happy to add this as one of the examples to the Note.