client API: restructure waiting, do log msg wakeup properly

Until now, availability of new log messages (through the mechanism
associated with mpv_request_log_messages()) did not wakeup the client
API properly. Commit 3b7402b5 was basically a hack to improve that
somewhat, but it wasn't a solution.

The main problem is that the client API itself is producing messages, so
the message callback would attempt to lock the client API lock,
resulting in a deadlock. Even if the lock was recursive, we'd run into
lock-order issues.

Solve this by using a separate lock for waiting and wakeup. Also, since
it's a natural addition, avoid redundant wakeups. This means the wakeup
callback as well as the wakeup pipe will be triggered only once until
the next mpv_wait_event() call happens.

This might make the wakeup callback be invoked in a reentrant way for
the first time, for example if a mpv_* function prints to a log. Adjust
the docs accordingly. (Note that non-reentrant beheavior was never
guaranteed - basically the wakeup callback is somewhat dangerous and
inconvenient.)

Also remove some traces of unneeded code. ctx->shutdown for one was
never set, and probably a leftover of an abandoned idea.

libmpv/client.h

@@ -1175,7 +1175,9 @@ void mpv_wakeup(mpv_handle *ctx);
  * must not make any assumptions of the environment, and you must return as
  * soon as possible. You are not allowed to call any client API functions
  * inside of the callback. In particular, you should not do any processing in
- * the callback, but wake up another thread that does all the work.
+ * the callback, but wake up another thread that does all the work. It's also
+ * possible that the callback is called from a thread while a mpv API function
+ * is called (i.e. it can be reentrant).
  *
  * In general, the client API expects you to call mpv_wait_event() to receive
  * notifications, and the wakeup callback is merely a helper utility to make