Modify the plotter ray tracing for its utilization in estimators

[vitmog]

Description

A minor modification of the Ray::trace() routine is proposed for its optimization for utilizing in particle transport applications, which allows:

• To start tracing from a known cell without recalculation of the initial geometry state;
• To keep cell_last for the permanent availability of the traced cell entity.

Details

The Ray::trace() routine provides a concise interface for geometry-related computations, and it is currently used for plotting purposes only. However, such a routine is also needed for estimators, which require the computation of track/optical distances. Such encapsulation of the geometrical functionality dramatically simplifies the implementation of many efficient techniques, especially for shielding problems. The currently relevant examples of possible usage are:

• The track-length family of estimators (see Ray tracing volume calculation and geometry testing #3645 for details of the implementation);
• Point estimator (it could be used in Point Detector Tally #3109).

Testing

The principle of the Ray class usage for such purposes was proved in #3645. Now, I have run the volume calculation tests for this version of the Ray class with the ray tracing volume estimator.
UPD. 19.02.26. The bidirectional ray tracing has been used for the volume calculation of the spherical geometry from #3645 inside the bounding box. It covers all four cases of the ray origin location: the combinations of known/unknown cell and inside/outside of the edge of the model.

Here, no tests were added due to the seeming excessiveness of the creation of a new artificial problem. However, if the tests are desired right in this PR, please let me know. I would be glad if someone could specify what tests exactly are needed then.

Checklist

• I have performed a self-review of my own code
• I have run clang-format (version 15) on any C++ source files (if applicable)
• I have followed the style guidelines for Python source files (if applicable)
• I have made corresponding changes to the documentation (if applicable)
• I have added tests that prove my fix is effective or that my feature works (if applicable)

[vitmog]

@GuySten I would be grateful if you could find time to critically review this and re-run the CI now after yesterday's crash.

[GuySten]

Looks good to me.

[paulromano]

I'd like to take a quick look at this one before we merge.

[vitmog]

It could be also useful to provide the ray origin point as an optional parameter of Ray::trace([r, u]|[p]) instead of passing it through the constructor Ray([r, u]|[p]) to prevent excessive creation/deletion of a specific ray entity for each tracing case. In this PR, I just reproduced the manner of Ray usage in plotters to make it shorter. If this change seems desirable, please let me know.

UPD. However, this functionality can also be efficiently implemented in a derived class of Ray, so modifying Ray::trace() is not necessary and might even be harmful.