Refs idaholab#20192

We need something better here but this is what was already in libMesh
and it ought to be good enough for now.

We'll need to wait for a libMesh update with a fix there before we have
DistributedMesh triangulation properly working.

We can't do this with our unique_ptr input mesh because of the move
assignent / dynamic recasting that happens later, but for everything
else we set it from the input file and don't touch it again.

Add a bit more readability, at Logan's suggestion

These mostly map 1-to-1 to parameters, but this way we get the
descriptions into Doxygen too.

Also link to the triangulator issue

We were getting this indirectly in Unity builds but we need it directly
for non-Unity.

This is a bit redundant (if we have a polyline hole we can easily
interpolate while generating it, and if we have a 2D mesh hole we
probably don't want to interpolate it and if we do we can refine it) and
the implementation was going to be a bit more hassle than I thought.

This should catch any potential mismatch when stitching.

With this plus some libMesh fixes I'm seeing tests pass on
DistributedMesh too.

With the fixes here and in libMesh we can run with DistributedMesh too
now.

libMesh added this support a while ago but I forgot to update MOOSE to
match.

So we can either regold the Exodus files or we can change the input
files; let's do the latter.

We seem to have some trouble with exodiff not caring if our block ids
or block names change, which does make it tricky to test a feature for
changing those ... but the Exodus limitation on multiple element types
in the same block is enough that this test still gives us *some*
coverage; if the triangle subdomain_id()s aren't all changed to
*something* then we find ourselves unable to write them.

This is a longer but clearer

Guaranteeing that we refine to the same final mesh while doing
floating-point comparisons in different compiled binaries is tricky.
Let's back off for now so we can pass the same tests on Mac and Linux.

The ./ is no longer necessary, and Output is not necessary for tests
that always get run --mesh-only

This avoids libMesh misidentifying a conflict when desired_area_func is
set.

We should probably support stitching in 1D, but that'd be a major
change.

Poly2Tri was flexible enough to handle either ordering, but the libMesh
hole boundary refinement code wasn't.

Thanks to Logan for catching these.

Thanks to Yaqi for prompting this

Just to make sure something screams if that option is ever mistakenly
removed.

Didn't realize I'd missed this one until I was double-checking Logan's
suggestions before resolving them.