Avoid reflow of shaped text

[SamBent]

Addresses #3099
This is a port of a servicing fix in .NET 4.7-4.8

Issue: Text that is narrower after shaping (e.g. applying ligatures and kerning) can reflow, yielding different line breaks than the original measure. Some words can disappear, and programmatic access can crash hard (FailFast).

Discussion:
The root cause turns out to be a faulty assumption in TextBlock's logic to choose a width to send to FormatLine in post-measure situations like render and hit-test. The intent is that FormatLine makes the same line-breaking decisions it did during measure. The faulty assumption is "Reflowing will not happen when Width is between _previousDesiredSize.Width and ReferenceWidth". [Comment quoted from TextBlock.CalcWrappingWidth. "Reflowing" means "different line-breaking decisions". Width is the width to be sent to FormatLine. ReferenceWidth and _previousDesiredSize.Width are the input and output widths, respectively, of the most recent measure.]

The assumption fails in cases where shaping (kerning, ligatures, etc.) decreases the width of the text. FormatLine uses unshaped glyph widths to determine how much text to consider in line-breaking decisions. But it reports the width of the lines it produces using shaped glyph widths. Thus choosing width = _previousDesiredSize.Width (shaped width) may cause FormatLine to consider less of the original text than it did at measure time, which can lead to reflowing.

In the repro, the text "ABCDE IAATA Corp." contains the sequence "ATA", which gets kerned closer together, making the shaped width of the first two words (83.3167) about 2.6 pixels less than its unshaped width (85.96). Measure calls FormatLine(115), which considers the full string (unshaped width 121.3633) and breaks after the second word, so ReferenceWidth = 115 and prevDesiredWidth = 83.3167. Then Render calls FormatLine(83.3167), which only considers the first two words (unshaped width 85.96) and breaks after the first word. This leads to the missing text and crashing text pointers.

The fix is to give FormatLine a width large enough to avoid reflowing. If the original width reflows, we do a binary search to discover the smallest width that doesn't reflow. It may change the result of rendering (and hit-testing), but only in the cases where reflowing occurred, i.e. only when the old results had missing text and were vulnerable to FailFast crashes. Those cases will pay a (slight) perf cost for the search, and the text may extend (slightly) outside the arrange-rect; this is preferable to crashing and losing text completely.