vo_opengl: avoid texture arrays for compatibility with Intel low quality crap

Commit a0b43a1 changed textures to an array, because additional
per-texture information was needed and managing this as array is more
elegant. This broke playback on Windows with Intel drivers (window
shows green video, even though subtitles/OSD work correctly). So change
it back to make it work again.

Affected driver: Intel(R) HD Graphics 3000 9.17.10.2932
Merge branch 'master' into low_quality_intel_crap

Conflicts:
	video/out/gl_video_shaders.glsl
	video/out/vo_opengl.c
cache2: uncrustify
stream: rename cache2.c to cache.c

I never found cache1.c (whatever it was named, if it ever existed).

cache2.h will be deleted later, so don't go through the trouble of
renaming it.
core: use STREAM_CTRL instead of accessing stream_dvd internals

Some code in mplayer.c did stuff like accessing (dvd_priv_t *)st->priv.
Do this indirectly by introducing STREAM_CTRL_GET_DVD_INFO. This is
extremely specific to DVD, so it's not worth abstracting this further.

This is a preparation for turning the cache into an actual stream, which
simply wraps the cached stream. There are other streams which are
accessed in the way DVD was, at least TV/radio/DVB. We assume these
can't be used with the cache. The code doesn't look thread-safe or fork
aware.
stream: misleading statement
stream_dvd: remove some deadly insane code

Of course all of stream_dvd.c (as well as libdvdread) is completely
insane, but at least this hack for ancient broken compilers on really
obscure platforms should be safe to remove.
stream_cdda, stream_vcd: check read buffer size

These assumed that the buffer provided with fill_buffer() was at least
sector sized, instead of checking the size parameter.

This is just a cleanup, since every caller made sure to align everything
on sector sizes, if a stream has the sector size set.
stream: move VCD specific stuff to stream_vcd

I don't even know what VCDs are. A prehistoric version of the DVD or so.
stream: remove unused function
stream: remove pointless check
support "-" as file name when encoding

This workaround sucks. avio just does not support "-" - and ffmpeg's
command line binaries work around it. FOUR TIMES. DIFFERENTLY.

WHY DOESN'T AVIO DO THIS RIGHT TO BEGIN WITH?
core: introduce separate VOCTRLs for screensaver stop/resume

This is slightly better because VOCTRL_RESUME/VOCTRL_PAUSE are usually
needed by VOs to know whether video is actually being played (for
whatever reason), and they wouldn't be passed to the backend's VOCTRL
handler, like vo_x11_control().

Also try to make sure that these flags (both pause state and screensaver
state) are set consistently in some corner cases. For example, it seems
enabling video in the middle of playing a file while the player is
paused would not set the paused flag.

If codec initialization fails, destroy the VO instead of keeping it
around to make sure the state is consistent.

Framestepping is implemented by unpausing the player for the duration of
a frame. Remove the special handling of VOCTRL_PAUSE/RESUME in these
cases. It was most likely needed because these VOCTRLs used to be
important for screen redrawing (blatant guess), which is now handled
completely differently. The only potentially bad side-effect is that the
screensaver will be disabled/reenabled for the duration of one frame.
x11: enable screensaver when paused, rename/change --stop-xscreensaver

Use the recently introduced screensaver VOCTRLs to control the
screensaver in the X11 backend. This means the behavior when paused
changes: the old code always kept the screensaver disabled, but now the
screensaver is reenabled on pausing.

Rename the --stop-xscreensaver option to --stop-screensaver and make it
more generic. Now it affects all backends that respond to the
screensaver VOCTRLs.
w32: enable screensaver when paused

This is quite similar to the previous commit.

Untested. I'm not sure if this is how it's supposed to work. At least
--no-stop-screensaver should work in any case.
command: use more standard time format for clock property

%k is not very standard. The manpage notes them as conforming to
"Olson's timezone package", and it's not standard C89, C99 or POSIX.
mingw doesn't provide it, and even some of the smaller Linux libcs
don't have support.

Use %H instead. This gives slightly different results, but I think
this is ok. Difference in behavior between these summarized:

  %k: "single digits are preceded by a blank"
  %H: "range 00 to 23"
cocoa_common: remove play/pause VOCTRL functions

Make VOCTRL_RESTORE_SCREENSAVER / VOCTRL_KILL_SCREENSAVER use the power
management functions directly.
image_writer: Add PNG filter option (default "mixed")

The use of filters prior to PNG compression can greatly improve
compression ratio, with "mixed" (ImageMagick calls it "adaptive")
typically achieving the best results.
gl_video: typo in comment
gl_video: fix scaling when image is cropped, or with no-npot

When the displayed image is cropped in Y direction (like using panscan
controls when playing 4:3 video on a 16:9 monitor), and separated
scaling is used, the texture size for the FBO holding the intermediate
result was calculated incorrectly. This could lead to artifacts, which
were quite apparent with extreme scale factors.

Actually, the size of that texture is OK, but the texture shouldn't be
used to hold the complete scaled image. Instead, it should be used for
the visible part of the image only. Because separate scaling works by
scaling in Y direction first, it's still fine to scale the image on the
full image width on the first pass. This helps avoiding artifacts on
the left/right border of the image when scaling in X direction, as the
scaler will try to fetch pixels from beyond the border. (The left border
is still kind of fine, but the right border will fetch garbage, unless
the texture is strictly sized, or explicit clamping is added to the
shader. Too much trouble, so using the full image width is simpler.)

Also fix some issues with no-npot mode, which enables use of power-of-2
textures. Maybe this mode isn't really useful anymore (modern hardware
is faster with smaller non-power-of-2 textures), but keep it for now.