Better support for custom line positioning

Nobody has claimed this yet.

There have been a few scenarios in integrating Parley with egui where I've thought "this would be easy to implement if only I could manually adjust lines' positions". For instance:
- Adjusting the starting X offset of a line because there's previous text on that same line. This can sort of be faked with an inline box, but there are a lot of complications around the fact that they can't be vertically aligned right now.
- Disabling line breaks entirely. egui has a single-line textbox widget that doesn't display newlines. If I could adjust the X and Y positions of lines, it would be pretty easy to just manually place one line after the other horizontally instead of vertically. If not, the alternatives would be to go over every code path that lets you set a textbox's contents and filter out newlines there, or to implement this type of layout in Parley itself.
- Not egui-related, but flowing text [into shapes](https://www.w3.org/TR/2004/WD-SVG12-20041027/flow.html) or around floated boxes. This requires manually positioning each span of text, since each one can start at an arbitrary x-coordinate and you can have multiple spans in a single row.

Right now, you can't just adjust the position of each line when rendering it because there are places in Parley that assume the lines will be laid out in a given way (the "cursor to point" and "point to cursor" methods, selection rectangle drawing, and AccessKit bounding boxes come to mind). There are often good reasons for Parley to make these assumptions--for instance, "cursor to point" can do a binary search over the Y-positions of each line, something which wouldn't work if they could be arbitrarily repositioned.

While the higher-level layout code is great for most use cases, I think an "escape hatch" to gain access to line-level granularity would be very useful and decrease the number of layout-related features that Parley itself would have to implement.

I think a good place to start would be moving some of the logic of the layout-dependent methods mentioned above into methods on `Line`. People who are fine with using the regular line layout could call into the existing methods on `Layout`, but those who need more control could call the `Line` methods and provide or apply the necessary position transformations themselves beforehand.

Start by tracing the layout-dependent methods mentioned in the issue: cursor-to-point, point-to-cursor, selection rectangle drawing, and AccessKit bounding boxes. Read how these methods use Layout and Line positioning, then determine the API and invariants needed for custom line placement. Done means the design supports transformed line positions without breaking regular layout behavior or dependent interactions.

Written by the indexing model from the issue text.