Utility for rebuilding InverseProblem with new times

[glwagner]

It's often useful to start a calibration problem by focusing on a narrow range of times at first to identify generally useful parameter ranges because

1. It's cheaper and
2. There are fewer particle failures / we can afford very small time-steps when integrating over a short time window.

Then as the calibration proceeds we might want to gradually expand / shift the range of times considered to inform parameters with more data.

Right now my current method is to update the priors manually and re-run the script. This is sort of necessary anyways, because I need to provide manual input into the priors update (ie I might want to ensure that certain regions of parameter space for certain parameters continue to be explored, despite that the current ensemble has collapsed to exclude it). This method has the downside that it involves a bit of sweat and manual labor.

In the future when we have better methods for controlling the rate at which the ensembles collapse, we might be able to design automated "schedules" for systematically adjusting the time window of the physical experiments that are being used for calibration.

I think a simple way to achieve this without changing any existing code is to design a utility like

update_times!(inverse_problem, new_times)

This utility will re-build the Observations and time_series_collector with a new_times vector, using the existing inverse_problem.observations (and leaving the existing simulation untouched, which will become important as our simulations get more and more complicated). This is hopefully fairly simple as we can use the original constructors, and cheap because our Observations concern a relatively small amount of data. We also have to make InverseProblem mutable, which is probably a good idea anyways.

cc @adelinehillier I think this might help with some of the stuff you planned to do too.

[glwagner]

One complication is how update_times! affects SyntheticObservations.transformation.time.

I think basically we'll only be able to support update_times! with SyntheticObservations.transformation.times isa TimeIndices{<:AbstractRange}, since we won't know how to recalculate either (i) discrete indices (times isa TimeIndices{Vector}) or (ii) weights (times isa AbstractArray).