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.
Also the naming is quite weird: Cpu**Time** but **Ticks**PerSecond.

I tend to look at the Windows source to see the intention. Here's the relevant code for win:

```c++
u64 Threading::GetThreadTicksPerSecond() { return 10000000; }
u64 Threading::GetThreadCpuTime() {
    FileTimeSucks user, kernel;
    FILETIME dummy;
    GetThreadTimes( GetCurrentThread(), &dummy, &dummy, &kernel.filetime, &user.filetime );
    return user.u64time + kernel.u64time;
}

u64 GetTickFrequency() { return lfreq.QuadPart; }
u64 GetCPUTicks() {
    LARGE_INTEGER count;
    QueryPerformanceCounter( &count );
    return count.QuadPart;
}
```

And Linux:

```c++
u64 Threading::GetThreadTicksPerSecond() { return sysconf(_SC_CLK_TCK); }
u64 Threading::GetThreadCpuTime() {
    // Get the cpu time for the current thread.  Should be a measure of total time the
    // thread has used on the CPU (scaled by the value returned by GetThreadTicksPerSecond(),
    // which typically would be an OS-provided scalar or some sort).

    clockid_t cid;
    int err = pthread_getcpuclockid(pthread_self(), &cid);
    if (err) return 0;

    struct timespec ts;
    err = clock_gettime(cid, &ts);
    if (err) return 0;
    unsigned long timeJiff = (ts.tv_sec*1e6 + ts.tv_nsec / 1000)/1e6 * GetThreadTicksPerSecond();

    return timeJiff;
}

u64 GetTickFrequency() { return 1000000; }  // unix measures in microseconds
u64 GetCPUTicks() {
    struct timeval t;
    gettimeofday(&t, NULL);
    return ((u64)t.tv_sec*GetTickFrequency())+t.tv_usec;
}
```

And here's some uses in the codebase:

```c++
pcsx2/gui/CpuUsageProvider.cpp
    // get the real time passed, scaled to the Thread's tick frequency.
82: u64 timepass    = (deltas.update * GetThreadTicksPerSecond()) / GetTickFrequency();
```

Analyzing the `UpdateStats()` function I see that it basically calculates the portion of the total frame/loop/... that a specific thread was running. It keeps historical values in a sort of ringbuffer.

The calculation of `m_pct_ee` reduces to (I know I'm not displaying the delta's as a subtraction, so it's simplified, but bear with me):

```c++
m_pct_ee = (deltas.ee * 100) / timepass;
// variable expansion =>
m_pct_ee = (GetThreadCpuTime() * 100) / (GetThreadTicksPerSecond() * (GetCPUTicks() / GetTickFrequency()))
// windows => 
m_pct_ee = (GetThreadTimes() * 100) / (10 000 000 * (QPC / QPCFreq))
// linux =>
m_pct_ee = ((clock_gettime(thread_clock).to_s * sysconf(_SC_CLK_TCK)) * 100) / (sysconf(_SC_CLK_TCK) * (gettimeofday().to_us / 1000000)) // ==
m_pct_ee = ((clock_gettime(thread_clock).to_s * 100) * 100) / (100 * (gettimeofday().to_us / 1000000))
```

It just seems that this (esp. the Linux part) could be simplified. It also seems (but this might be just an impression of mine, that a lot of precision is lost in the conversion to seconds). I actually don't know how it wouldn't, to be honest. I'm talking specifically about the Linux implementation, which first converts to seconds in an integer variable, which basically means that anything before seconds gets lost (correct me if I'm wrong). In my opinion, one should always keep the maximum detail around, in this case, it would be nice to standardize on nanoseconds. And to divide as little as possible. It's slow and destroys accuracy, especially with integers. With doubles, I can imagine it being a whole difference story with regard to precision. But we're not using doubles anywhere.

```c++
pcsx2/Counters.cpp
302:    s64 ticks = (GetTickFrequency()*500) / (fpslimit * 1000).ToIntRounded();
360:    s32 msec = (int)((sDeltaTime*-1000) / (s64)GetTickFrequency());
```

So basically `GetThreadTicksPerSecond()` just returns a number which you can divide `GetThreadCpuTime()` by to get seconds. Seconds is probably way too crude so that number will have to be multiplied again to show ms or something. This loses a whole lot of precision:

```
pcsx2/gui/ExecutorThread.cpp
209:            m_qpc_Start = GetCPUTicks();
225:            u64 qpc_end = GetCPUTicks();
227:                (u32)(((qpc_end-m_qpc_Start)*1000) / GetTickFrequency())).wc_str()
```

Similar story...

Lastly: one might think that `sysconf(_SC_CLK_TCK)` is a very natural "ticks per second" measure but perhaps it isn't, for two reasons:

- modern (Linux) kernels are tickless
- even if they weren't, and they'd have a timer interrupt every 10ms (100Hz), that _still_ wouldn't mean that the timer accuracy was only 10ms. A thread can yield before its quantum is used up, there's many ways to do so, but the most important ones are system-calls. Most system calls will make a thread yield. My guess is that a modern kernel will use `rdtsc` to keep the thread runtimes updated. Thereby gaining a lot of accuracy. Of course, a thread that performs no syscalls or anything of the sort would still have a 10ms granularity on a ticked kernel.

Now, I know there is probably a very good reason why you implemented it like you did @gregory38, and it's likely I'm missing something. I'm pretty interested in timing code so please enlighten me :).