Use face adjacencies to enter element from implicit complement

[pshriwise]

This contains a set of changes to allow the XDG::sgements call to use mesh adjacencies when finding an entering intersection into the volumetric mesh. XDG::segments is the primary call used to separate particle tracks for superimposed tally meshes in particle transport.

Currently, a finite ray given to segments can undergo a glancing intersection with a face when attempting to enter/re-enter the mesh. The query performed at the intersection location + a small amount can result in a failure to find an element in these cases, causing the method to return early as a result as it becomes unclear how to proceed in determining if the ray intersects any additional elements along it's length. This can prevent subsequent ray segments volumetric beyond this glancing intersection from being recorded.

The updates here use a new get_boundary_face_element to enter the element adjacent to the face. Meshes and transport simulations that have previously raise the warning in segments regarding failure to find an element after an intersection no longer do in this scenario and tally results match other tracklength estimator schemes in OpenMC. Further testing is warranted, however -- particularly integrated testing in the repo itself. While a good amount of testing was done for superimposed meshes that partially covered the domain, I don't think the geometries were such that glancing intersections were likely. We can now improve on this in benchmark and integrated testing.

The new get_boundary_face_element method is named as such because for MOAB meshes only these adjacencies are established in the direct access manager.

Alternatives

When the find_element call fails at the entering intersection location, fire another ray from the location + TINY_BIT under the assumption that the initial intersection discovered is a glancing intersection and repeat this process at the next intersection location should one be found closer than what distance remains for the finite ray. This option likely isn't as robust as entering an element via adjacencies nor is it as performant due to the (now) unecessary find_element call when entering a volumetric mesh element.

TODO:

• Provide tally equivalence data
• Add pathological test case