tests/kernel/sleep: Fix usleep test for fast ticks

The logic about minimal sleep sizes due to "tick" aliasing was
correct, but drivers also have similar behavior with "cycle" aliasing
too.  When cycles are 3-4 orders of magnitude faster than ticks, it's
undetectable noise.  But now on nRF they're exactly the same and we
need to correct for that, essentially doubling the number of ticks a
usleep() might wait for.

The logic here was simply too strict, basically.  Fast tick rates
can't guarantee what the test promised.

Note that this relaxes the test bounds on the other side of the
equation too: it's no longer an error to usleep() for only one tick
(i.e. an improved sleep/timeout implementation no longer gets detected
as a test failure).

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