Timing calculations are wrong

[gdamore]

There are a few issues with the timing calculations:

• A rounding / type conversion error can lead to wildly incorrect values (I had one report that came up at 7 seconds, but really took something on the order of a few dozen milliseconds). This was seen on Windows. Preserving the values as nanoseconds and only doing a division at the end gives better results. (And it appears that dividing by 1e9 is better than multiplying by 1e-9 if you want to avoid loss due to casting bugs.)

• The Linux MONONTONIC_RAW clock should not really be used. Besides not being portable, the values are not guaranteed to be microseconds -- and really you do want any adjtime adjustments because those reflect real-world timekeeping. (This makes it not as good for reproducible benchmarking, but the cpu clock is better for that anyway.)

• There is an order of magnitude bug in the POSIX timings, leading to times being reported as 1/10th their actual value (this lead to a lot of confusion for me at one point). Hint, 1 billionth is not 10e-9, but rather 1e-9.

I have a PR coming that addresses these.