Support for scheduling physical actions

[lhstrh]

Fixes #12.

Remaining issues:

• [ ] Sleep sometimes gets interrupted without the scheduling of a physical action. This is not a show stopper, but we should understand why this happens. We should introduce an extra variable to track the scheduling of events, so that we can restart the timer in lf_sleep_until instead of returning -1. See #15.
• [x] Even after implementing debounce, we occasionally get an interrupt when the button goes from low to high (i.e., a button release), as opposed to high to low (a downward press). We'd like to understand why this happens.

Tested solutions:

• [x] 2.2.6
• [x] Blink
• [x] 5.2.2
• [x] 5.2.3
• [ ] 5.2.5 (N/A)

A word of caution: This PR brings in a few extra runtime files, the changes in which should find their way into the mainstream reactor-c runtime once they are mature enough to include them.

[erlingrj]

We can use nrf_pwr_mgmt_run() to sleep. It checks if SD is enabled and also enables a more low power sleep. It calls __WFE twice so I think it is expected behavior that it returns quickly first

https://devzone.nordicsemi.com/f/nordic-q-a/62079/is-there-any-setting-for-using-wfe

[lhstrh]

Great find! Does it work?

[erlingrj]

I see that Edward added a 100ms delay in the printf macro. I don't see why that is necessary. Also it really messes with the temporal behaviour.

[lhstrh]

I think this was a hack around issues that should no longer exist with our updated runtime. Let's remove it.

[erlingrj]

Update:

1. Removed the 100ms delay
2. Moved to nrf_pwr_mgmt which works.
3. Overflow timer should trigger at t=0x00 not t=0xffffffff

[erlingrj]

@lhstrh The critical change here is that we keep next() in the critical section. Edward feared that there might be some racing condition if not. the threaded c-rutime apparently implements it like that and thus it is a more safe approach for now.