Allow filtering a specific mutex for tracking with NANO_TIMED_LOCKS

[wezrule]

This works by creating a wrapper around a std::mutex with a string constructor argument where a name for the mutex is specified. Users can register a mutex to track with the new NANO_TIMED_LOCKS_FILTER CMake variable, giving it a string matching one of the allowed mutex strings.

The actual files which changed are:
locks.hpp/cpp - Added nano::mutex class which has a constructor for passing in the name. In non NANO_TIMED_LOCKS builds, we want this class to have as little impact as possible (hence all the preprocessor guards).

CMakeLists.txt - Added new CMake variable NANO_TIMED_LOCKS_FILTER which currently allows any of ~20 named mutexes for tracking. I picked (I think) the most useful ones rather than add them all. Only a single one can be selected. Multiple is technically possible but not implemented here as theres a lot more value in targeting a specific one (due to interference due to slow generation of stacktraces on Windows for instance).

The mutexes which need tracking now use the new string constructor.

Updated core_tests/locks.cpp as if NANO_TIMED_LOCKS_FILTER is specified the tests would have otherwise failed fail.

Updated CI so that it is mandatory for nano::mutex to be used. It is not mandatory that it be named, the default constructor is fine to use.

[ghost]

DeepCode's analysis on #5cad3f found:

• ℹ️ 1 minor issue. 👇

Top issues

Description	Example fixes
Consider using a std::lock_guard object instead of locking and locking std::mutex explicitly. std::lock_guard will unlock the mutex once it runs out of scope and is destructed. Occurrences: locks.hpp:82	🔧 Example fixes

👉 View analysis in DeepCode’s Dashboard | Configure the bot