stream/cache: handle failure of seeking underlying stream

This could for example happen when serving an incomplete file from http,
and the demuxer tries reading data from the end of the file when opening
it (e.g. with avi). Seeking past EOF fails with http, so the file could
never be opened, and the cache would get stuck trying to seek to the
position.

We can't really make the cache report seek failure directly (it would
suck for various reasons), so just make the cache report EOF if seeking
fails.
sub: add --ass-style-override=force option

(The old "force" choice of that option is renamed to "force-default".)

This allows overriding native ASS script subtitle styles with the style
provided by the --sub-text-* options (like --sub-text-font etc.). This
is disabled by default, and needs to be explicitly enabled with the
--ass-style-override=force option and input property.

This uses in fact exactly the same options (--sub-text-*) and semantics
as the ones used to configure unstyled text subtitles.

It's recommended to combine this with this in the mpv config file:

ass-force-style="ScaledBorderAndShadow=1"   # work around dumb libass behavior

Also, adding a key binding to toggle this behavior should be added,
because overriding can easily break:

L cycle ass-style-override

This would cycle override behavior on Shift+L and allows quickly
disabling/enabling style overrides.

Note: ASS should be considered a vector format rather than a subtitle
format. There is no easy or reliable way to determine whether the style
of a given subtitle event can be changed without destroying visuals or
not. This patch relies on a simple heuristic, which often works and
often breaks.
sub: remove old style override option

Didn't work too well.
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.
client API: change mpv_wait_event() timeout semantics

Now a negative timeout mean an infinite timeout. This is similar to the
poll() system call. Apparently this is more intuitive and less confusing
than specifying a "very high" value as timeout if you want to wait
forever.

For callers that never pass negative timeouts, nothing changes.
client API: docs: some clarifications
client API: add API function that ensures total destruction

mpv_destroy() should perhaps better be called mpv_detach(), because it
destroys only the handle, not necessarily the player. The player is only
terminated if a quit command is sent.

This function quits automatically, and additionally waits until the
player is completely destroyed. It removes the possibility that the
player core is still uninitializing, while all client handles are
already destroyed. (Although in practice, the difference is usually not
important.)
client API: clarify mpv_get_wakeup_pipe docs

It wasn't necessarily clear how this works. Especially make clear that
the API user shouldn't expect that there's one byte per readable event
in the wakeup pipe. Actually, the reason why this currently won't work
is because property notifications can generate more events than wakeups.
The limit of 4096 is a more fundamental issue, but the event ringbuffer
is currently limited to 1000 entries anyway.

Also add some important comments to mpv_set_wakeup_callback.
client API: rename mpv_destroy() to mpv_detach_destroy()

A bit verbose, but less misleading. In most cases, the API user probably
actually wants mpv_terminate_destroy() instead, so the less-useful
function shouldn't have a simnpler name anyway.
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.