[alarm/android/tevtimer/others] apps using `require("sched").setAlarms` may suffer from alarm/timer bugs

[gfwilliams]

Related to #4232

fyi: @thyttan and @ticalc-travis

Basically there are some subtleties around putting an alarm/timer in the alarms array, which are now covered by require("sched").updateAlarm.

For instance:

• Ensuring that timers fire on the next day if currentTimeOfDay + timer > 24
• Ensuring alarms < current time fire on the next day

We handle this in require("sched").updateAlarm, which is called automatically from require("sched").setAlarm.

But it's NOT called from require("sched").setAlarms, because we don't know which alarms and new and which are old.

So right now we're in this situation where apps don't end up using updateAlarm, but work around the bugs in their own unique ways which may/may not work reliably.

• alarm has prepareXForSave
• android has a line like last = (event.d[j].h * 3600000 + event.d[j].m * 60000 < currentTime) ? (new Date()).getDate() : 0
• tevtimer doesn't appear to do any workarounds so I think will have issues if you snooze a timer near mignight
  ... and probably others that use setAlarms

The safe thing is to use setAlarm where possible, but I don't think it makes sense for the alarms app - I think we need to call updateAlarm before we stick an alarm in the alarms array, and ensure we remove existing workarounds from the codebase