Statepoint file loading refactor and CAPI function

[pshriwise]

Description

This PR contains a slight refactor of the statepoint loading so it can more cleanly be exposed as part of the CAPI.

It is also a continuation of #2390 in that the scenario where a statepoint is loaded with n_batches equal to settings::n_max_batches is softened to a warning. This allows previously executed statepoint files can be loaded into an initialized openmc.lib instance to recover tally information. An additional check for the current batch vs the max number of batches is added to openmc_next_batch to ensure that no particles will be transported in the case that the warning condition is triggered.

I think this results in reasonable behavior in the case that a user feeds a statepoint file from a complete OpenMC run back into the openmc executable without modification of the batches in the settings file: OpenMC will initialize, load the statepoint file, produce the warning message as part of the statepoint file load, run zero batches, and finalize. Importantly, it will not overwrite the existing statepoint file in this case either. It's somewhat unfortunate that a user will have to wait for problem initialization to get this result, but this was true before these changes as well.

We're using this as part of a project with Cardinal to load reaction rate tallies into a separately initialized OpenMC problem to leverage the depletion module for the Bateman eq. solve before sending updated material compositions back into Cardinal.

I went ahead and added a section on simulation restarts as I didn't see any information on it outside of the restart flag passed to the executable.

The restart regression test needed some updating after this to use a fixture that allowed for a check that the correct warning is present.

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 modified tests that prove my fix is effective or that my feature works (if applicable)

[pshriwise]

Update: to comply with expected behavior of openmc.lib's ability to iterate on batches beyond what is specified in the settings.xml, I moved the batches check into the openmc_run function so the early exit only applies when calling the openmc executable or openmc.lib.run.

[gridley]

very minor requests!

[paulromano]

Thanks for this improvement @pshriwise!

@gridley Can you let us know if you're OK with merging?