drivers/timer/systick: Improve clock slippage under irq_lock load

The SysTick logic looked logically sound, but it was allowing us to
set a LOAD value as low as 512 cycles.  On other platforms, that
minimum future interrupt delay is there to protect the "read, compute,
write, unmask" cycle that sets the new interrupt from trying to set
one sooner than it can handle.

But with SysTick, that value then becomes the value of the LOAD
register, which is effectively the frequency with which timer
interrupts arrive.  This has two side effects:

1. It opens up the possibility that future code that masks interrupts
   longer than 512 cycles will miss more than one overflow, slipping
   the clock backward as viewed by z_clock_announce().

2. The original code only understood one overflow cycle, so in the
   event we do set one of these very near timeouts and then mask
   interrupts, we'll only add at most one overflow to the "elapsed()"
   time, slipping the CURRENT time backward (actually turning it into
   a non-monotonic sawtooth which would slip every LOAD cycle) and
   thus messing up future scheduled interrupts, slipping those forward
   relative to what the ISR was counting.

This patch simplifies the logic for reading SysTick VAL/CTRL (the loop
wasn't needed), handles the case where we see more than one overflow,
and increases the MIN_DELAY cycles from 512 to 1/16th of a tick.

Fixes #15216

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