add continue feature for depletion

[lewisgross1296]

Description

This PR closes #2871. To summarize the motivation, I'd like depletion restarts to be a bit easier for users. If you set up a depletion simulation that doesn't end up getting run all the way (think hitting max wall time on an HPC or some other interrupt), the burden then falls to the user to correctly determine what time steps were not run and to create a new script that picks up where the other one left off. In my own experience, it is easy to make a mistake and re-run a simulation that is not what I desired.

All we do here is add a continue_timesteps flag (default to False) that adds a new logic block to the Integrator class. It would be useful in the above case and requires users to provide the Integrator with a set of timesteps and one of power/power_density/source_rate that matches what already exists in a prev_results passed to the Opperator.

With this flag, the depletion restart python script can now be exactly the same as the initial script, just with a continue_timesteps = True flag and a prev_results object loaded from a depletion_statepoint.h5 passed to the Operator. It could contain more timesteps at the end too, but the only requirement is that the data matches what is in the Operator provided to the Integrator for all the existing steps in the results.

This PR does not eliminate any of the existing capability of the depletion API, so all the old use cases/syntax for restarts remain. The flag is optional and defaults to False so no one will need to update past scripts with this change.

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)

[lewisgross1296]

Looking for input on this line (636)

[lewisgross1296]

I'm realizing now that I don't think openmc.deplete.Results has a get_source_rates() function. It seems like individual operators have a source_rates member, but I'm wondering if a method in openmc.deplete.Results parallel to get_times() would be useful for others. I noticed openmc.deplete.abc.Integrator has an __iter__() method but it doesn't return all the source rates, just the source rate and time (for a given iteration?)

It seems like maybe the appropriate line should be

completed_source_rates = operator.source_rates

though I'm wondering if the length of get_times() and operator.source_rates might have different lengths.

Tests were passing because I never added a test that hits this code, I will push up a test very soon (and likely it will fail)