Try for IEEE754-precise poly2tri triangulation results

[roystgnr]

@loganharbour is experimenting with adding CXXFLAGS for Haswell architecture compiler optimizations, and the fused-multiply-add instructions there are (via rounding differently) changing MOOSE XYDelaunay outputs. Compiling the whole thing with -ffp-contract=off fixes the problem, but we do want to allow fused-multiply-add in most of our code, so let's see if we can just disable non-IEEE754-compliant optimizations selectively.

Leaving this marked as draft until Logan can verify that it works for him.

[moosebuild]

Job Coverage, step Generate coverage on 0648c87 wanted to post the following:

Coverage

Inconsistent report tags were found between the head and base reports.
This can happen when reports are missing from either the head or the base.

Inconsistent tags:
32bit-np2_threads2
Full coverage report

This comment will be updated on new commits.

[roystgnr]

It turns out that this is insufficient, and even compiling all of src/mesh and src/numerics with safer FP arithmetic is insufficient, but if I also build all of src/geom with -ffp-contract=off then I finally get reproduceable triangulations in even unsafely-optimized MOOSE builds.

I'm not sure if I want to disable FMA optimizations for every single geometric calculation. I may have to make push/pop versions of those pragmas, and put them into enforce_ieee754.h and unenforce_ieee754.h or something, so I can start wrapping individual methods. Figuring out which individual methods need wrapping is going to take a while too.

[roystgnr]

Still haven't had much time to play with this, but I at least checked that the rest of src/mesh and src/numerics were overkill; all we need is the stuff in this PR plus some subset of src/geom

[roystgnr]

-march=native on elem.C alone doesn't trigger failures downstream ... nor on face_tri*.C ... actually, I can trigger failures downstream with just FMA on face.C. It's the quasi-circumcenter calculation that's doing it. Should have been an obvious risk point, in hindsight.

@loganharbour is fixing us downstream to use tests that enforce the quality of generated triangulations without enforcing the exact mesh refinement pattern, so hopefully this will be redundant with that, but I think in general it's still an improvement for our meshes to be reproduceable, as well as to have a couple handy headers to enforce reproduceable FP arithmetic elsewhere if it's needed.

[roystgnr]

This works with clang++ too, but I've still got nvc++ compatibility fixes to make before merging.