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.
options: change --sub-file behavior

--sub-file is actually a string list, so you can add multipel external
subtitle files. But to be able to set a list, the option value was split
on ",". This made it impossible to add filenames.

One possible solution would be adding escaping. That's probably a good
idea (and some other options already do this), but it's also complicated
both to implement and for the user.

The simpler solution is making --sub-file appending, and make it take
only a single entry.

I'm not quite sure about this yet. It breaks the invariant that if a
value is printed and parsed, you get the same value back. So for now,
just go with the simple solution.

Fixes #840.
manpage: document new --sub-file semantics

This was forgotten in the previous commit.
client API: trigger wakeup when creating wakeup pipe/callback

Since redundant wakeups are avoided now, it's easy to miss a wakeup when
creating/setting the pipe/callback after the client API was signalled.
If the client API is signalled, need_wakeup is set to true, and
wakeup_client skips writing to the pipe or calling the client API. That
this can happen is not very obvious to the client API, so trigger a
wakeup right on start in order to remove this special case.
client API: minor documentation fixes/enhancements
TOOLS: add script for generating a zsh completion script

As discussed in #775
build: generate and install zsh completion script
player: show "neutral" position markers for OSD bars

This commit implements them for volume and some video properties.
audio: add a "weak" gapless mode, and make it default

Basically, this allows gapless playback with similar files (including
the ordered chapter case), while still being robust in general.

The implementation is quite simplistic on purpose, in order to avoid
all the weird corner cases that can occur when creating the filter
chain. The consequence is that it might do not-gapless playback in
more cases when needed, but if that bothers you, you still can use
the normal gapless mode.

Just using "--gapless-audio" or "--gapless-audio=yes" selects the old
mode.
client API: disable LIRC input by default

Not only should using libmpv hog such global resources; it's also very
unlikely an application embedding mpv will ever want to make use of
this.
video: fix another cover art corner case

Playing a video and then an audio file with cover art kept displaying
the last frame of the video. This was because the hasframe flag was set,
perhaps due to redrawing the last video frame before the cover art image
is decoded.
player: hide some messages in verbose mode

This started getting annoying.
build: disable zsh completions by default, fixes e.g. cross compilation

The Perl script generating the completions actually invokes mpv, and it
runs during the build. This is not sane and breaks at least cross
compilation.

As a workaround, disable the completions by default for now.
osd: Center the volume icon in the osd font
command: redo ancient TV/DVB/PVR commands

Convert all these commands to properties. (Except tv_last_channel, not
sure what to do with this.) Also, internally, don't access stream
details directly, but dispatch commands with stream ctrls.

Many of the new properties are a bit strange, because they're write-
only. Also remove some OSD output these commands produced, because I
couldn't be bothered to port these.

In general, this makes everything much cleaner, and will also make it
easier to e.g. move the demuxer to its own thread.

Don't bother updating input.conf, but changes.rst documents how old
commands map to the new ones.

Mostly untested, due to lack of hardware.