[MAINT] Remove the pthread_once based implementation for existing singletons.

[ethouris]

There is a standard and acceptable way for creating singletons in C++: create the object as a local static variable and return its reference. Some of global objects, notably the CUDTUnited object, is implemented this way.

There was an alternative implementation provided, however, which was based on the call of pthread_once. This should be removed.

The local-static-based singleton (known from the Microsoft's documentation as "Magic statics") has been guaranteed to be initialized properly at the first call of the function containing it, including thread safety (deadlock-free) during the initialization. Hence there is nothing more to do than just create a singleton in the form of a local static.

The guarantees have been introduced in C++11, however what counts here is not which standard is in use during compiling, but rather whether a compiler provides these guarantees and under which condition - and this depends on whether the compiler supports it and whether any flags need to be turned on, regardless of what standard is to be honored by the compiler. We have actually three compiler categories here:

1. The GNU family - including clang. They can control this behavior through the -fno-threadsafe-statics; default is on.
2. The Microsoft compiler. This is supported (except that problems were identified on Windows XP and older systems) since Visual Studio 2015. In SRT we do not support older VS than 2018, and it's worth noting that no version of VS 2020 is now available to download.
3. The Intel compiler. The documentation describes a flag on Windows named /Zc:threadSafeInit-, not exactly mentioned anything about Linux/Mac versions, although the thread safety for local statics is on by default.

This means then, for all compilers this project is aware of, thread-safe locals are supported by the compilers and the support is turned on by default. SRT should provide some warnings in the documentation that it makes use of particular features (so, -fno-threadsafe-statics option shall not be used or anyhow enforced during the build), but the thread-safe locals can be otherwise stated as supported and no alternative solution is required.