XYMeshLineCutter bug fix

[pbehne]

Added utility function to determine if point is on line

Given a cut line, the XYMeshCutter deletes elements on one side of the
line.
When the line cuts through quad elements, those elements are converted
to tris and refined to form a new mesh boundary coincident with the cut
line.
To determine whether the cut line cuts through a given element, each
vertex of the element is plugged into the line equation f(x, y) = ax + by + c.
An (x, y) point is on the line if f(x, y) = 0.
Vertices residing on one side of the line have positive f(x, y) and
vertices residing on the other side of the line have negative f(x, y).
If two vertices of an element have differently signed f values, the
element is deemed to be cut by the line and is marked for conversion to
tri elements and further refinement.

This PR patches a bug in the above logic.
Previously, the mesh generator did not check if a given vertex lies on
the cut line.
These vertices were assigned to one side of the line.
In the case of a quad that is not cut by the line, but has an edge
coincident with the line, this can cause those elements to be
incorrectly marked for tri conversion and refinement.
While the final cut mesh was correct, this results in an irrelevant, confusing
warning that quad elements are being converted to tri elements.
This PR adds checks to determine and ignore vertices that lie on the
cut line.
These vertices are no longer used when determining whether an element is cut
by the line.

Closes #31795.

[moosebuild]

Job Test, step Results summary on d88152c wanted to post the following:

Framework test summary

Compared against b79a48d in job civet.inl.gov/job/3380566.

No change

Modules test summary

Compared against b79a48d in job civet.inl.gov/job/3380566.

No change

[moosebuild]

Job Documentation, step Docs: sync website on d88152c wanted to post the following:

View the site here

This comment will be updated on new commits.