Bug fixes for time series conservation task

[cbegeman]

Since we have changed the output frequency for the conservation AM to daily E3SM-Project/E3SM#6412, I have noticed that this causes a bug with time averaging. The time averaging config option movingAveragePoints assumes that the output frequency for all the time series tasks is the same. This PR introduces a factor of 30 to movingAveragePoints for the conservation task and fixes an issue with the time string correction for restarts.

[cbegeman]

@xylar I'm assigning this to you because I'm leaving on vacation. Hopefully the review will be easy.

[xylar]

I tested this with the test suite, after switching to a newer QU240wLI simulation that has the conservation check turned on. Results are here:
https://web.lcrc.anl.gov/public/e3sm/diagnostic_output/ac.xasay-davis/analysis_testing/chrysalis/conserv-output-freq-fixes/
Notably, the conservation analysis is there and seems to be averaged over 365 days:
https://web.lcrc.anl.gov/public/e3sm/diagnostic_output/ac.xasay-davis/analysis_testing/chrysalis/conserv-output-freq-fixes/main_py3.11/ocean/index.html#timeseries

I also ran just the conservation analysis (following an example I found from @cbegeman) for high res test 11. I ran both with a 365 day window and a 1-day window to make sure I saw the expected differences. Indeed, I did.

Here's 365:
https://web.lcrc.anl.gov/public/e3sm/diagnostic_output/ac.xylar/analysis_testing/20240626.HRr5-test11.chrysalis_conserv_test/ocean/index.html
Here's 1:
https://web.lcrc.anl.gov/public/e3sm/diagnostic_output/ac.xylar/analysis_testing/20240626.HRr5-test11.chrysalis_conserv_test_window_1/ocean/index.html

[cbegeman]

Thanks @xylar for fixing up syntax and formatting as well as testing. Feel free to merge whenever you'd like.

[xylar]

Yep, sorry about that. I meant to merge already :-)