linux/threads: simplify timer code

Possibly also changes the semantics. According to the docs, it should now be
equal to the Windows code (up to accuracy issues, of course).

ping @gregory38 

This is actually more of an alternative implementation so that I can learn and find out why the current implementation is the way it is.
> Euh, are you aware that m_pct_* only show a percentage of use of the current thread that means a number from 0 to 100.

Yes, for the percent usage it's probably enough. For everything else that might come in the future, it probably isn't.

It still doesn't address the why of `sysconf(_SC_CLK_TCK)`, it just doesn't make a whole lot of sense to base it on the internal kernel interrupt (which may or may not exist). The Windows code doesn't do it either.

> So a correct enough implementation (only 32 bits) will be:

For timing code, it's better to just use 64-bits calculations up until the final usage, even in 32-bits mode.

Besides, `GetThreadTicksPerSecond()` needs to be used in conjuction with `GetThreadCpuTime()` to get sensible values anyway. It makes little sense to first multiply by it, only to then divide by it. This seems like unneeded complexity, numerical accuracy loss and even performance loss (granted that performance is not important for the current usage, but we cannot presume about future usage).

> split 1e6 and 1e9 to avoid an long overflow.

I find this to be unnecessary contortions. Use 64-bit integers and only multiplications. 64-bit integers can handle about 300 years of nanoseconds.

Any way, you're the linux code maintainer so you decide. I'll care about the OSX version then, which is in another file. I initially tried this simplification so that I could have a cleaner base from which to `#ifdef` the OSX parts, like @juhalaukkanen did in his OSX branch. But in the end I decided to just create a new file specific for Darwin/OSX :).