Introduce new C API function for slice plots

[paulromano]

Description

This PR introduces a new openmc_slice_plot C API function that addresses several limitations of the existing API:

• Performance: When the openmc-plotter application makes calls via the C API, is has to call both openmc_id_map (for cell/material IDs) and openmc_property_map (for densities/temperatures). Both of these calls involve the same loop over pixels with a "find cell" call at each pixel. In the openmc_slice_plot function, both IDs and properties are retrieved at the same time, which will reduce the time for each slice plot in the plotter by 2×.
• Enhanced tally visualization: The plotter currently relies on ad hoc logic to perform visualization of spatial tally data. Matching each pixel to a matching filter bin could be done much more intuitively on the C++ side. My first shot at this was to have an openmc_filter_get_plot_bins function that is similar to the existing openmc_mesh_get_plot_bins, but once again this would involve another loop over pixels with "find cell" calls (because filters rely on a properly constructed particle with geometry state information). Instead, I've designed openmc_slice_plot to optionally take a filter index and return matching bin indices for each pixel. This will both speed up tally visualization in the plotter and allow us to plot things we can't currently (like MeshMaterialFilter).
• Arbitrary orientation slice plots: Our current slice plotting capability only handles axis-aligned slices. openmc_slice_plot is more general and allows arbitrary orientation slice plots by specifying two orthogonal span vectors that define the view.
• Cleaner interface: The openmc_id_map and openmc_property_map calls rely on a struct that has to be created on the Python side matching the C struct internally, which has always felt awkward to me. openmc_slice_plot is designed to take plain basic datatypes to avoid this.

Design questions

1. If we're OK moving forward with this, it begs the question of whether we should keep id_map, property_map, and _PlotBase around since slice_plot subsumes their capability.
2. How should this be presented on the Model class? Currently I have a separate slice_plot method but arguably it can (should?) be integrated into the existing plot method?

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]

If any of you want to try this out in the plotter, I've just put up a draft PR there: openmc-dev/plotter#172.

[pshriwise]

I think this looks great @paulromano. It should save us a lot of time plotting, particularly for models where find_cell is expensive. I know there's been a lot of desire for off-axis plots as well. Relatively minor comments from me here, but more to say on design and some of the questions you raised.

One limitation I see here that might be problematic is the specification of a single Filter. It would require a fair amount to add support for more than one I know, but if we want to rely on the filter matching in a more general way for plotting then I think we may need to support multiple Filters. (e.g. I often see mesh and cell/material filters used on the same tally).

For the plotter utility specifically it might be additionally beneficial to request the filter matches for all spatial filters at once so that the filter bin map doesn't need to be re-generated when switching tallies if the view itself doesn't change.

As for the id_map and property_map methods, I don't see any reason why we wouldn't deprecate them and have them return the appropriate subset of data from slice_plot for now.

Regarding Model.plot, Model.slice_plot returns raw data about the model (wondering if we might rename that to Model.slice in fact) and Model.plot does a lot of extra work to display an image, so we can keep the plotting bells & whistles there and it can rely on Model.slice_plot for the image data.

[pshriwise]

Perhaps Direction is a more appropriate type for the vectors u_span_ and v_span_ specified here.

[pshriwise]

Is this property still needed on the C++ side?

[pshriwise]

It looks like we can skip the filter set generation if the filter argument is None with a little refactor.