Fix application specific thread watchdog

[jeandube]

This fix sandwitches new blocking functions between THREAD_PAUSED/THREAD_RESUMED macros for application specific thread watchdog.
The application sets the SRT THREAD_XXX() macros to implement a thread watchdog. new blocking functions were added in the development toward 1.5.0 causing the thread watchdog to detect stalled threads that were legitimately blocked on event or timer and not gone wild in an infinite loop or slow callback.
By default the THREAD_XXX() macros are not defined so unless added in a multi-lines if or loop construction with no braces they can do no harm to most applications.

[maxsharabayko]

I wonder if placing the THREAD_PAUSED/THREAD_RESUMED calls inside wait_for is an option? It is possible for POSIX version. Or do you need to provide some reference to the place where the macro was called?

[ethouris]

Even better - as most of them rely on CSync, it has only one version, and could be placed inside. But I understand there was some reason to place these things also around whole loops that call the waiting function inside and then check a condition, not single waiting calls inside them.

Pity we can't have a version with lambda - this way the condition could be in the lambda and the loop inside.

[maxsharabayko]

Comment from @jeandube

The THREAD macro records the position yes so when a thread block or go wild we know the last THREAD_XXX() crossed.