We should firm up the semantics of `userlib::sleep*`

So, we've kind of avoided dealing with the timebase problem. (Well, okay, mostly me.)

Currently we express time in all APIs as "system ticks," where the system tick is set for the application (board+image) to whatever you want .... but in practice is milliseconds. And basically all code assumes it's milliseconds.

There are two problems with this.

1. We often need timing more precise than milliseconds, but changing the tick frequency, while easy, would break basically all drivers.
2. The userlib time-related APIs don't actually do what you'd expect.

On that second point -- if you call sleep_for(1), you will (in the absence of higher priority tasks keeping you from being scheduled at all) sleep for somewhere between 0ms and 1ms. In other words, it's really sleep_for_at_most_ms. Often, we actually want at least.

The actual kernel time API is based on absolute deadlines rather than intervals (basically to keep the kernel out of this argument) so I think we could fix this part in userlib.

Start by inspecting the userlib::sleep* APIs and the kernel time API described in the issue, focusing on how system ticks and absolute deadlines are represented. Compare the current interval behavior with the intended sleep semantics and account for existing drivers that assume milliseconds. Done means the timebase and sleep behavior are explicitly defined and consistently implemented.