fix maitake timer inaccuracy

[hawkw]

• [x] have a now: Fn() -> u64 that does rdtsc or however it is you say “rdtsc” in ARM/RISC-V/etc
  • or, really, probably a trait since you might want to have a “stupid Now” impl that’s an AtomicU64 that only gets bumped when advancing the wheel (so you can still have the current thing, basically)
• [x] have a Timer::now()/global free fn now() that does now
  • probably returning an instant newtype
  • so that user code can use the wheel’s time as a time source for other stuff
• [x] when creating a Sleep, do the following:
  1. immediately take now() (call that t0)
  2. when the wheel lock has been acquired, take now() again (t1)
  3. subtract the time elapsed between t0 and t1 from the sleep’s total duration when adding it to the wheel
  4. while we’re still holding the wheel lock after inserting the sleep, turn the wheel to t1

[hawkw]

(the way you say rdtsc on RISC-V is mcycle IIRC)

[hawkw]

when creating a Sleep, do the following:

• immediately take now() (call that t0)
• when the wheel lock has been acquired, take now() again (t1)
• subtract the time elapsed between t0 and t1 from the sleep’s total duration when adding it to the wheel

it turns out i was kinda wrong about this part; as a Sleep's deadline is already calculated immediately upon the sleep's creation, rather than after we get the wheel lock. so, inaccuracy is primarily just due to the fact that time "doesn't advance" while ticking the scheduler, in the current design, and not due to wheel lock delays.

• while we’re still holding the wheel lock after inserting the sleep, turn the wheel to t1

we should still do this part, though (and i haven't done it yet).