vo: warn if the VO doesn't support certain flags

Unfortunately, if a VO can't display something as intended, we can just
complain to the user, and leave it at it. But it's still better than
silently displaying things differently with different VOs.

For now, this is used for rotation only. Other things that we should
check includes colorspace and colorlevels stuff.
vf: print all image parameter information in verbose output
command: export rotation parameter

For completeness.
build: glob() is always available

glob() is mandated by POSIX. For the only non-POSIX platform we support,
Windows, we have our own replacement. So the ifdeffery is not needed.

Still leave the checks in the configure scripts, because they have to
decide whether to compile the replacement or not. (Although this could
be special cased to mingw-only, the wscript seems to make this hard.)
client API: make mpv_set_option set options natively

This should fix some issues, such as not being able to set the
"no-video" option with MPV_FORMAT_FLAG.

Note that this changes semantics a bit. Now setting an option strictly
overwrite it, even if the corresponding command line option does not.
For example, if we change --sub to append by default, then setting the
"sub" option via the client API would still never append. (Oddly, this
also applies to --vf-add, which will overwrite the old value when using
the client API.)

I'm doing this because there's no proper separation between the command
line parser and setting an option using the MPV_FORMAT_STRING format.
Maybe the solution to this mess would be adding format aware code (i.e.
m_option_set_node) to every option type, and falling back to strings
only if needed - but this would mean that you couldn't set e.g. an
integer option using MPV_FORMAT_STRING, which doesn't seem to be ideal
either.

In conclusion, the current approach seems to be most robust, but I'm
open to suggestions should someone find that these semantics are a
problem.