wayland: fix typo

So long in the code without me noticing. Embarassing!
build: add some warning cflags

These were in the old configure script too.

Two flags are explicitly tested, because I have no idea how widespread
support for them is, and testing them is just easier than trying to look
them up in various gcc/clang manuals. There are people using gcc 4.2
out there, so some caution is warranted.
old-build: drop support for anything but Linux, simplify

A lot of effort was spent on making the waf based build-system work
properly on all supported platforms, while the old configure script was
neglected. It seems that nobody maintains the non-Linux parts of the
configure script anymore, and all improvements go into the waf scripts.

Thus it makes no sense anymore to maintain the non-Linux parts. They're
just dead weight. Remove them completely.

Also apply some additional simplifications. For example, listing
enabled/disabled VO modules seems like a waste of effort.
old-build: accidental rewrite

This started as a bunch of smaller changes to make the old configure
script maintainable with minimum effort. It ended up as complete
rewrite, because at once point I started to like shell programming (I
hope this sickness is curable), and I wanted to see how small I can
make the configure script. The typical configure test is now 1 or 2
lines big, located in 1 or 2 places, instead of >15 lines and being
spread over 5 or 6 places.

The main "trick" is factoring the tests into a few generic, commonly
needed tests, instead of writing everything manually.
manpage: updates changes.rst

The situation has changed a bit since the days of mplayer2, so we can
use more/less diplomatic wording. Merge the two sections listing
changes from MPlayer and mplayer2. Mention the client API and Lua
scripting as alternatives to slave mode.

I'm calling MPlayer code "horrible". This is not meant as an offense,
but after turning around almost every line of MPlayer code, I believe
I have a right to say this. Sorry. I would say that MPlayer has a
surprisingly sane and simple architecture (for what it is), but much
of it drowned under a load of evil hacks or not-cleaned-up-yet code.
vf_vapoursynth: allow parallel processing

VapourSynth won't just filter multiple frames at once on its own. You
have to request multiple frames at once manually. This is what this
commit introduces: a sub-option controls how many frames will be
requested at once. This also changes the semantics of the maxbuffer sub-
option, now renamed to buffered-frames.
TOOLS/mpv_identify.sh: unbreak
vf_vapoursynth: avoid unnecessary waiting

It could in theory happen that the filter loop will enter a blocking
wait, even though it could make progress by emptying the list of
already-filtered images. I'm not quite sure if this could actually cause
a real issue - probably not.
manpage: changes.rst: minor fixups
vf_vapoursynth: add more debug output

Also, move num_requested() to where it's used. Remove newlines from VS
error messages. Remove an assert(0) on an error path.
vf_vapoursynth: fix debug output
vf_dlopen: remove buggy private name -> imgfmt conversion

This was presumably for backward compatibility,
but it was preventing the use of the new names.
vf_dlopen: update usage message to new-style args
TOOLS/vf_dlopen: use new pixelformats, fix usage for newstyle args
x11: wait until the window is mapped

This blocks everything, until the window is actually reported as mapped.

This fixes the race condition between VO initialization and mapping the
window, which resulted in possibly different window sizes, leading to an
immediate redraw, visible as flashing.

Note that if the map event never comes for some reason, we're out of
luck and will block forever.
x11: clear window on map

vo_x11_map_window() was attempting to clear the window on map. However,
it did so immediately after the map request. It probably assumed that
the drawing calls for clearing the window would be queued along with the
map request, and then executed in the right order. However, this
assumption was wrong - the map request first has to go to the window
manager (I guess?), so a lot of things happen before the window is even
mapped.

Fix this by moving the call to the MapNotify message handler, when the
window (apparently) becomes really visible.

I also tried to set CWBackPixel to black instead, but this seemed to
result in flickering on manual resizing.
x11: set the fullscreen state before mapping the window

This should get rid of some flickering. Since this actually skips all
the wacky fullscreening code on startup, this might lead to certain
wacky features to stop working. In this case, you'll have to use the
--x11-fstype option, and disable _NETWM_STATE_FULLSCREEN usage.
x11: remove unused stuff

Unfortunately, it looks like some Motif functionality is still needed
to allow for --no-border.
x11: remove a MWM hack

This was for Motif Window Manager. No, I don't care about Motif.
x11: replace--[x11-]fstype option with --x11-netwm

Simplifies the code a lot. You can still use --x11-netwm=no to disable
NetWM for whatever reasons.