Implementation of surfaces with custom implicit function

[pferney05]

Description

This pull request adds support for function-based implicit surfaces in OpenMC. It introduces a user-facing expression-tree interface for defining arbitrary 3D implicit functions, creates OpenMC surface objects from those functions, and enables them to be combined with standard regions through the existing Boolean geometry interface.

The implementation includes:

• A new openmc.implicit expression system for composing elementary symbols and operators into implicit functions.
• A new ImplicitSurface surface type with configurable isovalue support.
• Translation and rotation support through surface parameters.
• A Cached expression node that avoids redundant sub-expression evaluations during function evaluation.
• A legacy TPMS interface for pitch/isovalue-based definitions to ease migration from the previous TPMS implementation.
• Two interval-analysis ray-tracing solvers for finding the first positive root of a continuous Lipschitz function along a particle ray: a reference naive Lipschitz solver and a faster stack-based Lipschitz solver.
• User-adjustable solver parameters for absolute root tolerance, function tolerance, maximum iteration count, and crossing margin.

The motivation is to make OpenMC more robust and versatile for geometries that are difficult or inefficient to represent with constructive solid geometry primitives or triangular meshes, especially triply periodic minimal surface (TPMS) fuel concepts and graded TPMS lattices. Unlike standard quadrics, these surfaces generally do not have analytic ray-surface intersections, so the implementation uses numerical root finding along the ray.

The implementation was validated on eight calculations spanning seven geometries: a reference sphere, Primitive TPMS, Gyroid TPMS, Diamond TPMS, a strongly pitch-graded Primitive TPMS, a Squircle surface, and a Squared Circle surface. The implicit-surface sphere reproduces the standard OpenMC sphere result within statistical uncertainty, and the default solver parameters were found to give consistent results across all validation cases.

@sallustius @gridley @paulromano @ChasingNeutrons @shimwell You may be interested in this. This is a big PR which generalises #3292 to a wide range of functions.

Fixes # (issue)
N/A

Checklist

• I have performed a self-review of my own code
• I have run clang-format (version 18) 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)