overlap_check: make the ray direction independent of the compiler

[cyb3ralbert]

check_instance_for_overlaps picks the ray direction like this:

CartVect dir(rand(), rand(), rand());

The order in which function arguments are evaluated is unspecified in C++, so which rand() result lands in which component is left to the compiler. GCC evaluates right to left and Clang left to right, so the same source ends up checking along a different ray depending on which compiler built it:

compiler	resulting direction
GCC 11	(0.644860, 0.324763, 0.691871)
Clang 14	(0.691871, 0.324763, 0.644860)

(measured in the CI container, ubuntu-22.04 / glibc)

Both compilers are in the linux_build_test.yml matrix, so two supported builds of the same tool can check the same model along different rays. This patch just evaluates the three calls in a defined order: on Clang the direction is unchanged, and on GCC it becomes the same as Clang's.

I kept the change as small as I could. While looking at this I also tried replacing rand() with a uniform sample over the sphere, but that turned out to be a regression, so I'm not proposing it here. dir is used both as the bump offset and as the ray direction, and having all three components positive is what makes one of the two probes (+dir / -dir) land inside an axis-aligned convex corner. With a uniformly sampled direction whose components have mixed signs, neither probe enters the corner, and an overlap at a cube corner that the current code finds gets missed. So the positive-octant behaviour seems worth keeping, and I've left it alone — this also corrects the framing of #995, where I described the octant as a weakness. Sorry for the noise there.

Tested on ubuntu-22.04 / gcc 11 / MOAB 5.5.1: ctest passes 11/11 including overlap_check_test, and overlap_check gives the same results as before on the shipped models and on a few small ones I built by hand.

Happy to adjust the approach or drop this if you'd rather handle it differently.