wscript: update waf version check to the version in bootstrap.py
input: don't print warning when aboting playback via commands

I don't really see a reason for this.
client API: fix swapped pipe ends used with mpv_set_wakeup_callback

This was extremely wrong. It was never tested because nobody ever used
it (the feature was added for someone who never tried it in the end).
client API: use shared code for creating the wakeup pipe

Should be equivalent, reduces code duplication.
client API: don't use the mpv config files by default

This was always intended this way, and even documented in client.h. Due
to an oversight it was never actually implemented.

The intention is that mpv embedded in applications and "real mpv" don't
conflict. An API user can undo this by setting the "config" option to
"yes", if using the user's mpv config is desired.
client API: don't update properties in uninitialized state

If an API user calls mpv_wait_event() and mpv_observe_property() before
mpv_initialize(), it could happen that a property was accessed before
initialization, which is not ok.
client API: fix terminal usage

By default this is disabled. But if it's enabled, then we have to
account for proper states when enabling/disabling the terminal state
itself.
x11: cleanup motif hints handling

It seems we can't really get rid of this. There are no other hints to
remove decorations that work across all reasonable WMs, so we're stuck
with the ugly motif stuff.

But at least we can make the code for it less ugly.
client API: call wakeup callback if there are new messages

Listening on messages currently uses polling (every time
mpv_wait_event() has no new events, the message buffer is polled and a
message event is possibly created). Improve this situation a bit, and
call the user-supplied wakeup callback.

This will increase the frequency with which the wakeup callback is
called, but the client is already supposed to be able to deal with this
situation. Also, as before, calling mpv_wait_event() from the wakeup
callback is forbidden, so the client can't read new messages from the
callback directly.

The wakeup pipe is written either. Since the wakeup pipe is created
lazily, we can't access the pipe handle without creating a race
condition or a deadlock. (This is actually very silly, since in practice
the race condition won't matter, but for now let's keep it clean.)
client API: enlarge the message buffer if log level is high
build: prevent installation of client API example

This was never intended to be installed; waf just picked it up
automagically. There's also a closed ticket on github where someone
complains that the program "simple" is installed, and I didn't realize
at this point that it was actually installed by default when enabling
the client API.