Add support for active alarm windows in MPAS timekeeping

[amstokely]

This PR introduces user-defined active windows for recurring alarms in the MPAS timekeeping module. Previously, alarms could only be defined with an anchor time and a recurrence interval. Once the anchor was reached, the alarm would ring repeatedly until the end of the clock. There was no way to restrict alarms to a bounded time range.

Previous behavior

Alarms were defined only by anchor time and interval:

A ---------------- B ---------------------- E
^                 ^                        ^
Clock start    Alarm anchor              Clock stop

Once the anchor was reached, alarms rang every interval until the clock ended. There was no mechanism to disable alarms outside of a chosen window.

New behavior

With this PR, all alarms now have an active window. If the user does not explicitly provide a start or stop time, the window defaults to the clock start and stop times, so existing behavior is preserved. This allows the same logic to be applied consistently to both alarms with user-defined windows and alarms without them.

Timeline with user-defined window:

A                B          C            D                E
|----------------|----------|------------|----------------|
^                ^          ^            ^                ^
Clock start   Alarm anchor  Window     Window stop     Clock stop
                           start

Alarms do not ring before the window opens, ring normally inside it at the specified interval, and stop ringing after the window closes, even if the clock continues. Resets and direction changes interact correctly with these boundaries.

Internal structure

Several internal helpers were added to make the logic clearer and easier to maintain:

• mpas_is_alarm_active checks whether the current clock time is inside an alarm’s active window.
• mpas_prev_ring_in_window verifies whether the alarm’s previous ring time occurred strictly inside the window, using open-interval semantics (start, stop).
• mpas_time_in_interval performs the low-level interval membership check, supporting both closed [start, end] and open (start, end) intervals.

These helpers are not tested directly; instead, their correctness is validated indirectly through behavioral tests of alarms. This ensures that the implementation can be refactored without breaking tests, as long as the observable alarm behavior remains consistent.

Tests

A new test fixture (alarm_fixture_t) and suite (test_window_alarm) validate alarm behavior across 16 scenarios. These cover cases before and after the anchor, ringing at the window boundaries, ringing inside the window, leaving the window, delayed anchor times, resets, and clock direction changes.

mpas_reset_clock_alarm is invoked in several cases to confirm that the previous ring time is updated correctly. It is called at both window boundaries and inside the active window to exercise different internal bound checks that could fail in one case but not the other.

The tests focus strictly on behavior: they verify only whether alarms ring when expected, not how that behavior is implemented. This design allows the internal code to evolve without destabilizing the suite. At the same time, the tests serve as executable documentation of the alarm ringing contract, which was previously implicit. They will make future development in MPAS timekeeping more efficient, reliable, and safe.

[mgduda]

It looks from the GitHub view that all of this new code should be indented by three fewer spaces.

[mgduda]

While I can see some benefits to having a generic routine mpas_time_in_interval and to using that routine here, at some point the use of such a routine may obscure the essence of what's going on in my opinion. What happens when we eventually want half-open intervals? Which arguments to mpas_time_in_interval are the interval endpoints, and which is the time to be compared against those endpoints?

Instead, what about simply using code like this (adjust whitespace to taste) to replace the above three lines?

      mpas_prev_ring_in_window = (alarm % activeStartTime < alarm % prevRingTime &
                            .and. alarm % prevRingTime < alarm % activeStopTime)

[mgduda]

As an alternative to passing in the clock and always querying MPAS_NOW to determine whether an alarm is active, we could instead pass in an MPAS_Time_type instance representing the actual -- or hypothetical -- current time to be considered when determining whether the alarm is active. This would make the routine more general, and it potentially leads to less code.