build: add checks for some compiler warning flags
vo_x11: check allocation errors

Avoids a crash if allocation fails.
vo_x11: don't attempt to resize when unconfigured

Fixes #1347.

The previous commit actually fixes the crash.
options: deprecate 'lua' based options/dirs for 'script'

- --lua and --lua-opts change to --script and --script-opts
- 'lua' default script dirs change to 'scripts'
- DOCS updated

- 'lua-settings' dir was _not_ modified

The old lua-based names/dirs still work, but display a warning.

Signed-off-by: wm4 <wm4@nowhere>
vo_opengl: remove quadbuffer/anaglyph stereo 3D rendering

Obscure feature, and I've never heard of anyone using it.

The anaglyph effects can be reproduced with vf_stereo3d. The only thing
that can't be reproduced with it is "quadbuffer", which requires special
and expensive hardware.
scripting: fix/improve deprecation message

The message was missing a '\n', so it was merged with the next line,
which also typically caused it not to be printed with the colors for
warnings.

Print the full new path in the warning message. (Normally, cfg should
never be NULL, so accounting for this case is just for robustness.)
ao/wasapi: set the ao with the waveformat channelmap

hopefully this fixes #1350
lua: cosmetics: fix some include directives

Apparently, the atomics were used by the win32 subprocess code. This
code was moved to a separate file, but the atomics.h include was
forgotten.
client API: be more lenient about mpv_suspend/resume mismatches

Before this commit, this was defined to trigger undefined behavior. This
was nice because it required less code; but on the other hand, Lua as
well as IPC support had to check these things manually. Do it directly
in the API to avoid code duplication, and to make the API more robust.
(The total code size still grows, though...)

Since all of the failure cases were originally meant to ruin things
forever, there is no way to return error codes. So just print the
errors.
ao_alsa: add ridiculous hack to deal with braindead ALSA behavior

dmix reports channel layouts it doesn't support. The rest of the
technical part of the story is in the code comment.

This seems to be the only reasonable way to fallback from trying to
initialize certain devices (like dmix) with multichannel audio. We could
probably add support for such padding channels to our audio chain or to
ao_alsa itself, but this would probably be much more work than this
commit.

What dmix does is probably a bug. I've tried to report it to ALSA. Thay
have a link on their website to a bug tracker, but it's a dead link, and
has been for years. I've posted to alsa-devel, but received no reply.
I'm thus assuming this absolutely retarded behavior is by design, and
nothing will happen to improve upon it.

I'm considering sending Lennart Poettering a "thank you" email, because
with PulseAudio, multichannel audio just works (although some other
things just don't work).
ao_alsa: remove old multichannel method

The "old" method (before the ALSA channel map API) used device aliases
like "surround51" to set the channel layout. The "interesting" part was
that these devices usually redirect to a hardware device. This means
playing stereo would lead you to the "default" device (dmix), while e.g.
5.1 to "surround51", which automatically takes care of the fact that
dmix can't do 5.1.

This is pretty much nonsense, though. It shouldn't depend on the damn
input media file whether the player is going to use shared access (dmix)
or exclusive access (direct hw device).

As a consequence, by default ao_alsa will do only what dmix can do. If
the user actually wants multichannel, he has to select a suitable hw
device with --audio-device. From there on, the correct speaker mapping
will be ensured via the channel mapping API.

The change is preparation for making multichannel output the default (as
far as supported by the audio output API). Of the common APIs, only ALSA
messes up beyond repair, so I feel like this change is needed.

On ancient alsa-lib versions, only stereo and mono can be played with
this branch.
audio: make native channel count the default instead of stereo downmix

This should work well with most audio APIs, except ALSA. A long-winded
explanation is provided how to make ALSA multichannel output work.

All other AOs should have no such problems. Of course it's possible
that previously unknown issues arise, because I assume that enabling
multichannel audio is actually relatively rare.

This also disables codec downmix by default, which could change the
audio output due to different mixing in the codec and libavresample.

Fixes #1313.