Add interval distances for line segments

[w0rm]

This PR implements 4 functions from https://github.com/ianmackenzie/elm-geometry/issues/3

As there will be more coming up, what would be the most generic way to document such functions?

Not sure if the tests make sense, because the added functions are very simple and the implementation reads like definition.

[ianmackenzie]

Good question on the documentation, that is tricky! How about something like

Measure the distance of a line segment along an axis. This is the range of distances along the axis resulting from projecting the line segment perpendicularly onto the axis. Note that reversing the line segment will not affect the result.

and

Measure the distance of a line segment from a plane. If the returned interval:

• is entirely positive, then the line segment is above the plane
• is entirely negative, then the line segment is below the plane
• contains zero, then the line segment crosses the plane

Note that reversing the line segment will not affect the result.

[ianmackenzie]

For tests, maybe something like

Test.fuzz3
    Fuzz.lineSegment3d
    (Fuzz.floatRange 0 1)
    Fuzz.plane3d
    "signedDistanceFrom"
    (\lineSegment t plane ->
        let
            point =
                LineSegment3d.interpolate lineSegment t
        in
        LineSegment3d.signedDistanceFrom plane lineSegment
            |> Interval.contains (Point3d.signedDistanceFrom plane point)
            |> Expect.true "Interval should contain distance for any point on the line"
    )

since that checks the real mathematical definition - the signed distance interval of a line segment from a plane should be the union of the signed distances of all (infinitely many) points on that line segment. It's a pretty trivial check for line segments, but should be a bit more meaningful for things like bounding boxes, circles etc.

[ianmackenzie]

By the way, I might end up leaving this PR open for a little while - I'd like to push out a 3.2 version pretty soon, but we're getting very close to the size limit on docs.json. So my preference would be to publish 3.2 before adding a ton of signed-distance functions, and then we can take our time figuring out how to solve the docs size issue. (I've filed an issue to ideally have size counted as gzipped instead of raw, but there are other possible approaches like moving some higher-level docs out to a separate 'guide' site or even splitting elm-geometry into elm-2d-geometry and elm-3d-geometry.)

[w0rm]

@ianmackenzie apologies for the delay! Just updated my PR.

[ianmackenzie]

Cool, thanks! Should actually be easier to merge this now since the docs.json limit has been bumped up a bit =)

By the way, is there a reason you force push changes? That does seem to confuse GitHub Desktop sometimes if I'm trying to keep a local checkout updated...

[w0rm]

@ianmackenzie I force push to keep cleaner commit history.