Time to move on, two years after 2017.

On Windows, we keep using our own implementations, because GCC
implements std::mutex and std::condition_variable with pthread
emulation, which is not a good choice.

Prepare the transition to std::mutex.

Just like std::condition_variable, which however has no way to specify
the std::mutex directly.

Closes https://github.com/MusicPlayerDaemon/MPD/issues/507

Since we switched from autotools to Meson in commit
94592c14, we don't need to include
`config.h` early to properly enable large file support.  Meson passes
the required macros on the compiler command line instead of defining
them in `config.h`.

This means we can include `config.h` at any time, whenever we want to
check its macros, and there are no ordering constraints.

This compile-time check got lost during the Meson transition.

Apparently on hurd-i386 __GLIBC__ is defined, but the pthread
implementation is special and cannot be used with constexpr. Hence
exclude __gnu_hurd__.

So long, autotools!  This is my last MPD related project to migrate
away from it.  It has its strengths, but also very obvious weaknesses
and weirdnesses.  Today, many of its quirks are not needed anymore,
and are cumbersome and slow.  Now welcome our new Meson overlords!

Some Audio plugin (such as ALSA, and soon CoreAudio) already support microsecond level buffer time. However, current interval less than 1000 microseconds will cause a bug that the code treated as 0 ms.

There is a POSIX definition for sched_setscheduler(), but Linux does
not implement that; instead of changing the process's scheduler, it
only affects one thread.  This has caused some confusion among
application developers and C library developers.

While glibc implements Linux semantics, Musl has made their
sched_setscheduler() function an always-failing no-op, causing the
error message "sched_setscheduler failed: Function not implemented".

 http://git.musl-libc.org/cgit/musl/commit/src/sched/sched_setscheduler.c?id=1e21e78bf7a5c24c217446d8760be7b7188711c2

Instead of relying on the C library which may be unreliable here, we
now roll our own system call wrapper.

Closes #218

Juse in cas glibc gets a wrapper for the system call which would then
conflict with ours.

This attribute shall be used only for IsInside() to make this safe
against a race condition described in #188:

> There is no requirement on the implementation that the ID of the
> created thread be available before the newly created thread starts
> executing.

http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_create.html):

This means that on some pthread implementations (e.g. Haiku), the
assert(thread.IsInside()) could fail.

Closes #188

This method is only used inside assert().

Use the "==" operator instead of pthread_equal().

This allows us to eliminate two boolean flags which are there to avoid
race conditions, and made the thing so fragile that I got tons of
(correct) thread sanitizer warnings.

Use the "==" operator instead of pthread_equal().

This allows us to eliminate two boolean flags which are there to avoid
race conditions, and made the thing so fragile that I got tons of
(correct) thread sanitizer warnings.

Only _WIN32 is defined by the compiler, and WIN32 is not standardized
and may be missing.

Closes #169