Fix winding number solver near endpoints

[jneem]

In the winding number calculation, it when the ray's crossing was close to an endpoint it was possible for the solver to mistakenly put the solution outside of [0.0, 1.0]. This fixes the solver so that it always finds a solution (which it must, because the segment is continuous and we check that its y values span the y we're looking for).

Fixes #531.

[tomcur]

This looks good, thanks! A changelog entry mentioning improved robustness would be great.

I'm idly wondering whether there are still adversarial inputs possible at the level of paths (not segments), e.g. where two near-identical and mirrored segments fail slightly differently such that an x is falsely considered inside or outside... for any reasonable horizontal distance to the path edges perhaps not.

[jneem]

As you already alluded to, if the point's x coordinate is very close to the segments then you can definitely get inconsistent answers from adjacent segments, but I think that's ok: the point is close to the boundary anyway and so errors are allowed.

As long as there's a reasonable horizontal distance, I think we're safe against inconsistencies -- I added a little comment to winding_inner giving a hint as to why. But for example, if you have a decreasing-y segment followed by an increasing-y segment and the point's y coordinate is exactly at the vertex or slightly above then (with this PR) we are guaranteed to say that both segments cross the point's y coordinate. If there's a reasonable horizontal distance involved, we'll get the x coordinates correct enough and either get a winding number of 1 - 1 or 0 + 0. On the other hand, if the point's y coordinate is strictly below the vertex then we'll way that neither segment crosses the point's y coordinate.

The other case (increasing-y followed by decreasing-y) handles the exact equality case differently, but it should still be ok 🤞