Account for floating point inaccuracies

[wfdewith]

Currently, we calculate aggregated advances based on their component advances, such as line advances being a sum of run advances and inline box widths, and run advances being a sum of cluster advances. All of these advances, including the aggregates, are always f32, which means that inaccuracies may occur based on the order in which the component advances are being added. See this for an example of the problem.

This is generally not a problem since those inaccuracies are very small, but it does pose a problem for invariants such as layout.width <= layout.max_content_width as discovered in #259.

@tomcur offered a suggestion in #259, but I wanted to move discussion to a new issue.