drivers: fix overflow in ClockDevice.sleep_ms

[matpala]

ClockDevice.sleep_ms computed time_ms * 1000 in u32, which overflows from 4,294,968 ms (about 71.6 minutes): a panic in Debug/ReleaseSafe and illegal behavior in ReleaseFast/ReleaseSmall. This converts in u64 instead, still with a single sleep_us call.

The conversion uses shifts (1000 = 1024 - 16 - 8) rather than a multiply: on AVR, which doesn't link compiler_rt, a runtime u32 multiply needs __mulsi3 and a u64 one __muldi3, so sleep_ms with a runtime argument (e.g. TLV493D) didn't link there. Checked with Zig 0.17.0, ReleaseSmall, on the ATmega328P: the shift version links and has no multiply calls.

Adds a test for 0, 1, the last value that fit, the first that overflowed, and maxInt(u32); it fails on the current code with integer overflow.

[mattnite]

Did you try enabling compiler_rt?

[matpala]

Yes. With .bundle_compiler_rt = true on the ATmega328P, compiler_rt itself fails to build with Zig 0.17.0 (address space 'flash' cannot cast into address space 'generic', ziglang/zig#37090, still open), which is why the AVR ports turn it off.

[Grazfather]

1. This adds avr-specific comments in a generic driver. I would just say that it avoid using mult instructions. Please test against multiple targets (e.g. wch, esp32c3, rp2040, and atmega328) + disassemble and provide evidence
2. Do you see evidence of the ms wasting time storing to the stack and then copying to an arg. I wonder if using a bunch of @as(u64... might avoid this. Again, please test against those targets.