Fix optimality when negative values are in use

[basil]

@robertknight I spoke too soon in #103. We were fine against restriction 2, but not against restriction 1: a particular optimization relied on restriction 1. I've fixed that here by removing that optimization when restriction 1 is present. It is demonstrated in a new unit test, which fails like this before the fix to src/layout.ts:

Chrome Headless 127.0.6533.88 (Linux x86_64) layout breakLines does not lose the optimum when negative values are present FAILED
        AssertionError: expected [ +0, 1, 6 ] to deeply equal [ +0, 3, 6 ]
            at Context.<anonymous> (build/tests.bundle.js:13506:27)

After the fix to src/layout.ts, the new unit test passes. While I was here, I also added comments explaining the reasoning for why we are safe with regard to both Restrictions 1 and 2.

[robertknight]

Thanks again for the detailed notes.

[robertknight]

I missed that the middle box had a width of -2 rather than 2 until I read the code below.

[basil]

Thanks @robertknight! Could this please be released?

[robertknight]

Done - https://github.com/robertknight/tex-linebreak/releases/tag/v0.8.1

[basil]

Thank you very much!