Highlighting of suboptimal thread placements on SMT CPUs

The base idea is to detect when multiple threads have been running on the same CPU core and then try to find (to compute) whether a better placement of threads on the CPU cores might have been possible.

If a more optimal thread placement is found, cpugraph will then try to compute how much it impacts the overall performance of the machine and how much it momentarily impacts the applications subjected to suboptimal thread placement.

The approximate slowdown if two threads are executed on the same physical core instead of being executed on separate cores is about 25%. This number has been determined by measuring the slowdown of running two instances of "stress-ng --cpu=1" on a Ryzen 3700X CPU. Note that the slowdown might be different for applications other than stress-ng and on CPUs other than Ryzen 3700X. However, 25% seems like a reasonable generic value for use in the cpugraph's algorithm determining the approximate performance impact of suboptimal SMT scheduling decisions.

A description of what is being shown to the user:

• In the CPU bars drawing area:
  • Bars corresponding to threads experiencing SMT scheduling issues are (optionaly) painted using a different color
• In cpugraphs' properties dialog:
  • Whether the CPU supports SMT
  • Number of SMT scheduling incidents detected by cpugraph
  • An estimate of how suboptimal placement of threads might have impacted the overall and the momentary performance of the machine

Suboptimal SMT scheduling cases are quite rare (at least in Linux):

• They are impossible to happen if the CPU is under full load
• They are rare if the CPU is running one single-threaded task
• They tend to occur especially when the CPU is running about $(nproc)/2 threads

This feature is currently supported only on Linux and isn't supported on other Unix-style operating systems.

Closes: #11 (closed)