FPS counter highly inaccurate on LibreHardwareMonitorLib.dll due to possible too quick value update calls.

Describe the bug
FPS counter is highly innacurate, ie. randomly giving 40, 50, 70, 120, 130 readings to a game that runs on steady 60 FPS with v-sync.
Reported system is Windows 11 with Radeon RX 6600 GPU + Adrenaline v. 25.6.1 software, with turing-smart-screen-python with both exe installer and github pulled latest (on day 17.07.2025) source code. The LibreHardwareLib version is 0.9.4.

To Reproduce
Steps to reproduce the behavior:

1. Launch turing screen program with theme showing FPS counter
2. Launch any fullscreen game that shows FPS reading, with own internal FPS counter.
3. Watch and compare in-game and turing screen values.
4. See error in large disjoint between FPS shown by turing screen and in-game counter.

Expected behavior
FPS counter on turing screen showing correct (in game with v-sync on 60 Hz monitor being 59 and 60 FPS) value.

Logs
none required

Screenshots / photos of the Turing screen
none required

Environment:

• Turing Smart Screen 3.5" , with Hardware sensors (LibreHardwareLib)
• turing-smart-screen-python v3.9.3 main branch
• Windows 11
• Python version 3.13
• AMD Radeon RX 6600 GPU

Additional context
Bug has been tracked and located by Bug report issuer.
It seems that in library\sensors\sensors_librehardwaremonitor.py, both Gpu.fps() and Gpu.stats() methods call indirectly get_hw_and_update(), which results in LibreHardwareLib being called to update too fast (the author estimates mili/microseconds of difference) which makes the readed FPS counter value incorrect.
This suspicion has been supported by moving Gpu.fps() method code to Gpu.stats() and making Gpu.fps() method just one line, returning previously updated value - which resulted in 100% correct FPS reading. (Note This modification somehow voids program logic, making Gpu.fps() method dependent on Gpu.stats() method call, which in result will not work (FPS counter will not be updated) without prior Gpu.stats() call - which is minor sacrifice and can be easily resolved by proper program logic update.)

Start in library\sensors\sensors_librehardwaremonitor.py and inspect Gpu.fps(), Gpu.stats(), and their indirect get_hw_and_update() calls. Reproduce the readings against a game's counter, then trace the update sequence and verify that the Turing screen reports stable values for a v-sync-locked game without relying on an unrelated method call.