(Mostly) fixes #1436

The root cause of the above issue is that the logic for using and validating custom insulinPeakTime (and by extension, the errors that are logged from said logic) was all the way down (in the sense of a call stack) in calculate.js. This means that the validation logic was running many more times than necessary (and in the case of when the values fall out of the tolerable range, an absurd amount of log messages).

Here's what the typical flow might look like for that:

oref0-pump-loop.sh defines and invokes calculate_iob
calculate_iob calls run_remote_command 'oref0-calculate-iob [...]
oref0-calculate-iob.js uses ../lib/iob as generate
lib/iob/index.js uses lib/iob/total.js(called either 1 or 48 times depending on bool currentIOBOnly)
lib/iob/total.js uses lib/iob/calculate.js (called for each non-future treatment that is more recent than dia_ago)

The changes I made move such value handling (both that in calculate.js and in total.js; thought the former was the source of pain, both were moved for consistency) to index.js, where the handling can be done once and the values can be used many times in calcualte.js and total.js.

As this change asserts, why would we fetch the values, validate them, and log on error in calculate.js (which can, in the worst case be called 48 * the number of treatments that are being evaluated in the DIA times) when we can do so once in lib/iob/index.js and just pass the values down?

This is a much better situation, because we only get one log message for each invocation of lib/iob.

The fix isn't perfect (and why I say it only mostly fixes #1436), because invoking oref0-meal results in somewhere between 15 and 20 lib/iob invocations, and thus an equivalent number of log messages. Not ideal, but much more palatable than the original number.

oref0-pump-loop.sh defines and invokes refresh_pumphistory_and_meal
refresh_pumphistory_and_meal calls run_remote_command 'oref0-meal [...]
oref0-meal.js users ../lib/meal as generate
lib/meal/index.js uses lib/meal/total.js (called once)
lib/meal/total.js uses lib/determine-basal/cob.js as detectCarbAbsorption (called for each treatment + 1)
lib/determine-basal/cob.js uses lib/iob as get_iob (once for each bucketed_data value, seems to be between 15 to 20 times on average)

Arguably a similar (if not more effective) fix for the logging issue would be to have just commented out the lines that were doing the logging entirely, but getting rid of one of the only ways that the user might know their config has out-of-range values didn't feel good.

On that note, I think it might be worth considering how we can get the log message into the pump-loop log instead of just the shared-node log, since I don't think there is much (if any) documentation that directs users to look in the shared-node log.

That, and maybe the pump-loop should just fail on out-of-range config values? It would certainly be more noticeable, but maybe also not desirable since it's an issue that we can correct programmatically by using the min/max allowed value.