Fix negative distances from bins_crossed for CylindricalMesh

[pshriwise]

Description

For some context, during the process of tracing a track segment along the mesh elements, the PeriodicMesh::distance_to_grid_boundary method uses the initial position as-is, while the get_indices transforms the initial coordinates to local coordinates by default. I'd like to change this to be something more consistent, but I'll save that for another PR.

Two problems are fixed here:

1. Coordinates were adjusted for the origin more than once in the process of calling bins_crossed for cylindrical meshes. They are adjusted in once raytrace_mesh and again in the CylindricalMesh implementation of distance_to_grid_boundary. The additional transformation in distance_to_grid_boundary has been removed.
2. When a particle partially overlaps the mesh, a get_indices call is used to determine which element the particle passes into (if it does at all). The coordinates passed have already been transformed and an additional, incorrect, transformation is applied within this method.

I've updated the filter_mesh regression test to use an origin with a z-value and adjusted the z grid of the original mesh to obtain an equivalent mesh with an origin. Without the changes here in mesh.cpp the regression results failed produced negative flux values. With the changes applied the test passes without changes to the regression results.

Fixes #3369

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)

[paulromano]

Thanks for the PR @pshriwise. See comment below regarding the local_coords method:

[RemDelaporteMathurin]

@pshriwise @paulromano do we know when the next release containing this fix will be out?

[shimwell]

Tracking releases history I see over the last 137 months there have been 22 releases of OpenMC, averaging a release every 6 months. Assuming this continues then I would anticipate a release around mid October.

Hopefully before that we will have a pip install where you can install the latest version of the repo with a command like this
pip install git+https://github.com/openmc-dev/openmc.

In the meantime building from source is always an option.