Prevent sysfs read latency from interfering with GUI updates

This patch moves /sys/.../scaling_cur_freq reads to a thread that is separate from the GUI thread. In addition, in case the read latency is longer than the refresh time of the cpufreq plugin, the plugin will not schedule a new sysfs read until the currently running batch of sysfs reads terminates.

The implementation protects data shared among threads using mutexes. The data protected by a single mutex is very small (less than 100 bytes). It is improbable for the timing of the critical sections in different threads to interfere with each other.

Some examples of reading CPU info from sysfs files:

• Ryzen 7 3700X (8 cores, 16 threads): latency of a batch of 16 reads of /sys/.../scaling_cur_freq files: up to 200 milliseconds

• Ryzen 9 3900X (12 cores, 24 threads): latency of a batch of 24 reads of /sys/.../scaling_cur_freq files: up to 800 milliseconds

• The sysfs latency depends on the frequency of the reads. If reading more than 2 times per second then the latency of each batch of reads is 1 ms. But if reading less than 1 time per second then the latency is much longer: 200ms or 800ms.

Closes: #15 (closed)