kernel/timeout: Fix timeout "sooner" computation

There was an edge case in the timeout handling (exposed by, but not
strictly related to, the recent timeslice fix): the next_timeout()
computation would include time slice expiration as a clamp on the
result, but this would be invoked also on the z_set_timeout_expiry()
path which gets hooked on entry to a new thread which is needed to set
the timeout in the first place.  So if no other timer interrupt was
scheduled, it was possible to miss the first timeslice interrupt after
thread scheduling.

The explanation is much longer than the fix (use <= as the comparator
instead of <).

In practice this was only being hit in the existing test suite on
riscv miv running under renode using non-default clock rates.

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