New Interpolation Strategies

[kylecarow]

ninterp currently ships Linear, LinearUniform, Nearest, Step/StepLower/
StepUpper. This tracks strategies worth adding on top of those, based on auditing a
real downstream consumer (QCDLab/neopdf) that
hand-rolls all of the following today because none of them exist in ninterp.

• CubicC2 (originally proposed here as CubicSpline) -- global C² cubic
  spline, 1D-ND, configurable boundary condition (NotAKnot/Natural/Clamped/
  Periodic). In progress via Cubic interpolation family: CubicC1 and CubicC2 #55: renamed from CubicSpline, and a full
  corner-derivative cache added for Interp2D/Interp3D so 2D/3D queries are an O(1)
  Hermite-patch lookup instead of re-solving the recursive tensor decomposition on
  every interpolate() call. This supersedes the Bicubic/Tricubic proposal
  originally listed below: that capability is now CubicC2's own corner cache, not a
  pair of separate dimension-specific types.

• CubicC1 (originally proposed here as CubicHermite) -- local cubic
  Hermite spline (C¹, finite-difference derivative estimate). No global tridiagonal
  solve, cheaper to build than CubicC2, and in the same family as the recipe LHAPDF
  uses, so it's not interchangeable with a natural spline for consumers wanting that
  kind of local, no-global-solve behavior. Not a drop-in for LHAPDF/neopdf parity,
  though: LHAPDF's bicubic scheme is an order-dependent, successive-1D construction
  (interpolate x first, derive the y-derivative from finite differences of the
  already-x-interpolated cross-sections), not a symmetric per-knot corner-derivative
  spline; CubicC1 stays symmetric and order-independent, matching CubicC2's
  existing architecture. QCDLab/neopdf reimplements the LHAPDF recipe five times:
  LogBicubicInterpolation (2D), LogTricubicInterpolation (3D),
  LogFourCubicInterpolation (4D), LogFiveCubicInterpolation (5D), plus a standalone
  consolidated InterleavedHermite whose own doc comment notes it uses "the same
  algorithm" as the others; consumers wanting exact LHAPDF parity still need their own
  implementation, as neopdf already has.

  Ship v1 plain: derivatives from unclipped finite differences -- the same
  derivative-estimate principle neopdf's own version uses at the 1D level, though the
  overall construction differs as above -- the minimum bar. The derivative-estimate
  method is a #[non_exhaustive] enum from day one, not a bool or a field bolted on
  later, so monotonicity-preserving and alternative derivative formulas can land
  afterward without a breaking change:

  #[non_exhaustive]
  pub enum CubicC1DerivativeMode {
      FiniteDifference,
      // Pchip: Fritsch-Carlson monotonicity-preserving clipping.
      // Akima: weighted-secant-slope derivative estimate, resists overshoot near
      // flat regions; standard alongside Pchip in scipy/GSL/MATLAB.
  }

  Gate any future non-FiniteDifference mode out of Strategy2D/Strategy3D::validate
  until its 2D/3D mixed-partial behavior is verified (the 1D formulas are
  well-established literature, the mixed-partial case for each isn't). Loosening a
  validation error later is non-breaking; shipping an unverified guarantee isn't as
  easily undone.

• Chebyshev -- global/spectral polynomial interpolation, barycentric
  formula on Chebyshev-spaced nodes. Confirmed in scope: a different interpolation
  family entirely, not competing with the cubic family above, useful for smooth
  functions needing high accuracy from few points. neopdf implements this twice --
  LogChebyshevInterpolation and a second, batch-oriented
  LogChebyshevBatchInterpolation that recomputes the same barycentric-weight math
  for multi-point speed. The latter carries its own
  TODO: potentially merge this with LogChebyshevInterpolation -- neopdf considers
  this duplication unresolved on their end too.

Coordinate-space transforms (tracked separately)

GridTransform/Transform/ValuesTransform: see #56. Not a new interpolation
method -- a composable wrapper around any strategy above (or Linear/Nearest) that
interpolates in a transformed coordinate space (log, sqrt, reciprocal, ...) instead of
the raw one -- useful for data spanning many orders of magnitude, known nonlinear
relationships, or keeping output within a range a raw spline can't guarantee.
QCDLab/neopdf hand-rolls a Log*-prefixed strategy per combination today
(LogBicubicInterpolation, LogTricubicInterpolation, LogChebyshevInterpolation)
precisely because there's no composable alternative; this retires that naming
convention in favor of one wrapper type, rather than the crate growing a matching
Log* type per strategy.

Other future directions (not committed, no known consumer yet)

Distinct from everything above: nothing here is backed by a real downstream consumer
hand-rolling it today, which is the bar the rest of this issue was held to. Listed so
they're not lost, not because they're planned.

• Tension spline -- cubic spline with a tunable tension parameter trading
  curvature-continuity for overshoot control. Geophysics/GIS domain (GMT's
  greenspline).
• Trigonometric/Fourier interpolation -- for uniformly-sampled periodic signals,
  the DSP-native alternative to CubicC2's Periodic boundary condition.

Non-goals

• No radial basis function / scattered-data interpolation, no kriging, no
  smoothing/regression splines -- out of scope for a rectilinear-grid, exact-
  interpolation crate. Different problem class (fitting through noisy or non-gridded
  data), not a gap in this one.
• No B-spline basis or approximating/smoothing B-spline as separate strategies --
  either the same interpolant CubicC2 already produces via a different internal
  algorithm (not a new capability), or curve fitting rather than interpolation, same
  reasoning as the point above.