vf_vapoursynth: fail gracefully if filter init requests frames

Some VS filters will requests frames from their parent filters while
they're initialized. Thy do this in a blocking manner, and
initialization will not succeed until the frame request is satisfied.
This deadlocked mpv, because we can feed frames to the filter only after
initialization is finished.

Return an error instead of deadlocking.

Note that we (probably) can handle frames being requested during init
fine, as long as the requests don't block initialization. But we can
distinguish this situation, and a simple test seems to indicate VS
usually doesn't do this.

See #1168.
build: make zsh completion directory configurable

Also, use the zsh default location (rather than the Debian one).
libmpv/mpv.def: add mpv_command_node[_async]
client API: check result ptr in mpv_command_node

This follows the docs, which say the result parameter is optional.
build: install input config files into doc dir

Users using binary packages don't have obvious access to them, so this
seems like a good idea.
x11: don't wait until window is destroyed

This can hang if the window was destroyed externally (or that's what I
suspect happens), and we somehow didn't receive the DestroyNotify event.
I'm not sure why we wouldn't receive this event (since it should just be
in the xlib event queue), but on the other hand there's no real need to
wait for window destruction.

This essentially reverts 97fc74e2.
vf_vapoursynth: when seeking, recreate only if it's already created
vf_vapoursynth: factor stuff
vf_vapoursynth: return dummy frames if frames are requested during init

An attempt at fixing #1168.

I see black frames flashing, so it's certainly not perfect.
build: update waf to version 1.8.1

Fixes #1164
build: remove useless function
command: make volume/mute unavailable if audio is not initialized

This does nothing good. This reverts a change made over a year ago - I
don't remember why this was originally done this way.

The main problem is that even if the volume option is set (something
like "--volume=75"), the volume property will always return "100" until
audio is initialized. If audio is uninitialized again, the volume
property will remain frozen at its last value.
command: don't display non-sense if volume is unavailable

Showed "Volume: (unavailable)%". That was dumb.

The message string is now a bit convoluted; mostly because the property
expand syntax can't do "if-else", just "if".

CC: @mpv-player/stable