drivers/timer/nrf_rtc_timer: Fix round-up for rapid tick rates

When the tick rate was less than MIN_DELAY, bumping a "too soon"
expiration by just one tick may not be enough and we could
theoretically miss the counter.

Instead, eliminate the MIN_DELAY computation and write to the spec:
NRF guarantees that the RTC will generate an interrupt for a
comparator value two cycles in the future.  And further, we can test
at the set point to see if we "just missed" the interrupt (i.e. zero
cycles delay) and flag a synchronous interrupt.  So we only need to
miss a requested interrupt now for the special case of exactly one
cycle in the future, and then we're only late by one cycle.  That's
optimal.

Also fixes an off-by-one in the next cycle computation.  By API
convention, an ticks argument of one or less means "at the next tick"
and not "right now".  So we need to add one to the target cycle to
avoid incorrectly triggering a synchronous interrupt.  This was a
non-issue when a tick is longer than a hardware cycle but is needed
now.

Also handles the edge case with zero latency interrupts (which are
unmaskable) which might mess up timing.  This was always a problem,
but we're more sensitive now and it's comparatively more likely to
occur.

Signed-off-by: Andy Ross <andrew.j.ross@intel.com>