Symmetrize calls to intersects() and distance()

[aprokop]

Currently, we are missing the following symmetric version of the calls:

struct intersects<PointTag, TetrahedronTag, Point, Tetrahedron>;
struct intersects<PointTag, TriangleTag, Point, Triangle>;
struct intersects<SphereTag, BoxTag, Sphere, Box>;
struct distance<PointTag, SegmentTag, Point, Segment>;
struct distance<PointTag, TriangleTag, Point, Triangle>;

It is apparently pretty hard for me to remember to provide the second version every time I add a new intersection or distance algorithm.

Thus, this PR automatically reverses the arguments if it detects that the specialization is missing arguments in the original order. This should take care of it fully.

[dalg24]

Did you consider defining a macro instead

#define ARBORX_TEST_DISTANCE_EQ(geometry1, geometry2, distance) \
BOOST_TEST(ArborX::distance(geometry1, geometry2) == distance);
BOOST_TEST(ArborX::distance(geometry1, geometry2) == ArborX::distance(geometry2, geometry1))

[aprokop]

I don't see any advantage to macros. In addition, it would require changing a ton of code to wrap things into parenthesis to be able to call the macro.

[dalg24]

Quality of the error logging

[aprokop]

It will currently fail like

check sym_distance(Point{0.5, 0.5, 0.5}, box) == 1 has failed [0 != 1]

There's minimal difference with the original failure of

check distance(Point{0.5, 0.5, 0.5}, box) == 1 has failed [0 != 1]

[dalg24]

I slightly prefer the macro approach but I can live with the function.
distance is fine with a negative value to report the issue but intersects needs update

[dalg24]

How to we signify that the intersects(a, b) does not match intersects(b, a)?
We would need to report error by some other channel like abort or throw an exception

[aprokop]

You are correct in that the function signature does not have a proper error channel. I don't think it is a big deal, though.

[dalg24]

Fine