Don't allow hanging whitespace to contribute to wrapping

[taj-p]

Before

After breaking on whitespace, following whitespace characters would wrap to the next line. I.e., in the below test of:

"First                           Second"

The subsequent whitespace following "First" would form its own line.

After

All the whitespace following "First" is "hanged" off the first line and does not contribute to the second line's advance nor alignment.

This, I believe, is the intended behaviour per [spec](https://drafts.csswg.org/css-text/#soft-wrap-opportunity, per code comment, and how the browser behaves.

parley/parley/src/layout/line_break.rs

Line 370 in e581c08

// We hang any overflowing whitespace and then line-break.

[nicoburns]

@taj-p Looking the CSS spec (https://drafts.csswg.org/css-text/#white-space-property) it looks to me like both the existing behaviour and the new behaviour in this PR are specced. Specifically, the existing behaviour corresponds to white-space: break-spaces and the new behaviour corresponds to white-space: pre-wrap (additionally, Blitz's pre-processing of white space in the TreeBuilder makes it sometimes behave more like white-space: normal / white-space: pre).

There is also a newer version of the spec which doesn't change the spec'd behaviour but does decompose the white-space CSS property into orthogal white-space-collapse and text-wrap-mode properties (https://drafts.csswg.org/css-text-4/#white-space-processing).

---

In lieu of a full white-space implementation, I would consider approving a change of the default to be more like white-space: pre-wrap as this PR does. However, I am concerned about the (multiline) editing use case where I think hanging more than one chracter of whitespace probably isn't appropriate? So perhaps we need a style to control this so that we can retain the existing behaviour or some alternative improved behaviour for editing?

---

I would be interested in your updated thoughts on this once you have read sections 3 and 4 of https://drafts.csswg.org/css-text-4

[taj-p]

@taj-p Looking the CSS spec (https://drafts.csswg.org/css-text/#white-space-property) it looks to me like both the existing behaviour and the new behaviour in this PR are specced. Specifically, the existing behaviour corresponds to white-space: break-spaces and the new behaviour corresponds to white-space: pre-wrap (additionally, Blitz's pre-processing of white space in the TreeBuilder makes it sometimes behave more like white-space: normal / white-space: pre).

There is also a newer version of the spec which doesn't change the spec'd behaviour but does decompose the white-space CSS property into orthogal white-space-collapse and text-wrap-mode properties (https://drafts.csswg.org/css-text-4/#white-space-processing).

In lieu of a full white-space implementation, I would consider approving a change of the default to be more like white-space: pre-wrap as this PR does. However, I am concerned about the (multiline) editing use case where I think hanging more than one chracter of whitespace probably isn't appropriate? So perhaps we need a style to control this so that we can retain the existing behaviour or some alternative improved behaviour for editing?

I would be interested in your updated thoughts on this once you have read sections 3 and 4 of https://drafts.csswg.org/css-text-4

I really appreciate this Nico. Just letting you know that I will get back to this sometime in the next couple weeks.