Add multi-index support to apply_time_correction

[jon-proximafusion]

Summary

apply_time_correction now accepts an iterable of time indices in addition to a single integer. When given an iterable it returns a list of derived tallies, one per index; scalar input is unchanged and still returns a single Tally.

This makes it cheap to post-process a D1S mesh tally at many shutdown times. Previously each time of interest required a separate call, and every call re-read the tally results and re-reshaped the sum/sum_sq/mean/std_dev arrays. Now the arrays are read and reshaped once and shared across all requested indices.

Behavior

• Scalar index → returns a single Tally (unchanged API).
• Iterable index → returns list[Tally], one per index, in the order requested (unordered/partial sequences are honored).
• Each derived tally is bit-for-bit identical to the corresponding single-index call — the per-index math is the same broadcast-multiply-and-reduce as before.
• When sum_nuclides=True, the summed result no longer stores sum/sum_sq. The public accessors already return None for any derived tally, so this matches develop's observable behavior. It avoids two full-size multiplies per index on data nothing reads, and fixes Tally.sparse on summed tallies (whose stored arrays were otherwise shaped inconsistently with the popped ParentNuclideFilter).

Performance

Reading and reshaping the tally arrays once (instead of once per call) avoids the repeated I/O and reshaping when post-processing at many times; larger meshes and more timesteps benefit most. The per-index arithmetic is unchanged, so this is a constant-factor saving on setup, not a faster algorithm.

Testing

Adds test_apply_time_correction_multi_index, which checks that each element of a multi-index call matches the corresponding scalar call (mean, std_dev, filters, and sum/sum_sq), that unordered/partial index sequences are honored, that scalar input still returns a single Tally, and that the original tally is left unmodified.

Relationship to #104

This PR is the bit-for-bit implementation. #104 is an alternative that computes the summed parent-nuclide reduction with an einsum contraction — faster still for large mesh tallies, but matches develop to machine precision (~1e-15 relative) rather than bit-for-bit. The two are mutually exclusive; pick whichever trade-off is preferred.

Fixes # (issue)

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)