Optionally compute bounding boxes in Mesh.material_volumes

[paulromano]

Description

This PR adds an optional bounding_boxes flag to the mesh material volume calculation so that each (mesh element, material) pair can also return an axis‑aligned bounding box. The primary implementation lives in Mesh::material_volumes; it uses low‑level atomic compare‑exchange intrinsics to achieve thread‑safe min/max updates for bounding box expansion. In the future, when we are able to utilize newer features in OpenMP 5, a lot of the ugly atomic-related code can be significantly simplified.

The main motivation for this feature is representing the decay photon source in mesh‑based R2S calculations. At present, R2SManager uses a MeshSource plus a domain constraint for each element‑material pair, which can be extremely inefficient when a material occupies only a tiny portion of an element. With bounding boxes available, the updated workflow here is to forgo MeshSource and instead build a Box source per element‑material combination, using the computed bounding box to restrict sampling while still applying the material domain constraint.

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)

[shimwell]

Would it be worth adding a note to our future selves

Suggested change

	// Helper function equivalent to std::bit_cast in C++20
	// Helper function equivalent to std::bit_cast in C++20
	// TODO refactor using std::atomic_ref https://en.cppreference.com/w/cpp/atomic/atomic_ref.html when moving to C++20

[paulromano]

There already is a comment down in the beginning of MaterialVolumes::add_volume that discusses using OpenMP, which would be my preferred approach:
https://github.com/paulromano/openmc/blob/dc515205c0a58a1910c017b394bd76619b8ffd15/src/mesh.cpp#L212-L215

Let me know if you'd like to see something additional

[GuySten]

Looks good to me!
@paulromano, do you think we should deprecate openmc.MeshSource in a follow-up PR?

[paulromano]

No, I think MeshSource may still come in handy in other use cases so I don't think we should deprecate it.

@pshriwise @eepeterson did either of you want to review this before merging?