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
configure: reject older libswresample

mpv still builds with ffmpeg 1.0.x, however libswresample keeps cuasing
trouble. In older releases, libswresample simply crashed when
downmixing. In somewhat newer versions, it produces distorted output and
downmixing isn't even close to correct.

With ffmpeg release 1.1 (ffmpeg git tag n1.1), everything seems to work
fine. The release uses 0.17.102 as libswresample version, so bump the
required minimum version to that.
add Travis-CI integration

Travis-CI [1] is a continous integration cloud service. It is free for
open-source projects and tigthly integrated tiwh GitHub so there is really
no reason for us not use it. :)

For now we are going to do a total of 4 builds, mainly to test ffmpeg/libav
API breakage:

 * ffmpeg-stable, libass-stable
 * ffmpeg-git, libass-stable
 * libav-stable, libass-stable
 * libav-git, libass-stable

The compiler that is currently used is clang for two reasons:

 * running 8 build targets would be quite wasteful and take a long time
 * clang is less tested and used during development than gcc (especially on
   linux)

Currently Travis doesn't support OS X environments alongside Linux ones [2].
When it will, we will add a fifth build target to test OS X compilation
breakage.

README was moved to markdown to add the little build status image. I ran some
tests with my GitHub fork and couldn't get images to show up using ReStructured
Text.

 [1]: https://github.com/travis-ci/travis-ci
 [2]: travis-ci/travis-ci#216
vf_dlopen framestep filter: add a parameter for the phase

also, default to 0-indexed frame counts (so by default, the 1st frame is
output). Old behaviour can be done by -vf dlopen=./framestep.so:42:41.
vf_dlopen framestep: step width of 0

This is now defined to mean to never output any frame again (except for
the first).
travis: DRY up the yaml file

Use YAML's anchor/reference syntax to DRY up the YAML file. Also fix a bug
that caused the IRC notification to always take place (even on success).
travis: fix typo

[ci skip]
Silence some compiler warnings

None of these were actual issues.
m_option: fix -vf-del in profiles

We don't bother with option verification (as it happens in profiles),
because it's barely possible.
m_option: fix parameter comparison for vf-toggle

The vf-toggle option parsing (normally used for runtime video filter
switching only) was missing comparing the parameter values. Fix this,
and also make the code a bit more robust.
vf_lavfi: remove redundant statements
configure: map --enable-sdl2 to autodetection

Commit 02bbd87b disabled SDL linking by default. This commit followed
the ancient mplayer convention of disabling detection of compiler flags
with  --enable-* switches. Unfortunately, this makes compiling with SDL
enabled a pain.

Make --enable-sdl/sdl2 use autodetection, even if it's inconsistent with
most other --enable-* switches. The same is already done for
--enable-openal, though.

Based on a pull request by qyot27.
mplayer: re-add some legacy slave mode output for issue #92

In the long run this should be done differently. ID_... output sucks.
This commit will be reverted as soon as I have a good idea how this
should be done properly.
dec_video: remove emms usage

libavcodec generally shouldn't have this problem anymore (if libavcodec
ever had it). All other video decoders are gone. In any case, if this
commit actually causes regressions, these are libavcodec bugs and should
be fixed there instead.
dec_video: get rid of two global variables
options: remove dead -dr1 option
demux_mkv: support dirac in mkv

Nobody uses this, and this is an absolute waste of time. Even the user
who reported this turned out to have produced a sample manually.

Sample produced with:

wget http://diracvideo.org/download/test-streams/raw/vts/vts.LD-8Mb.drc
mkvmerge -o dirac.mkv vts.LD-8Mb.drc

mkvmerge writes a sort of broken aspect ratio. libavformat interprets it
as 1:1 PAR, while demux_mkv thinks this is a 1:1 DAR. Maybe libavformat
is more correct here.
demux: workaround for -demuxer mpegts -correct-pts

Using -demuxer mpegts -correct-pts triggered the assertion in
ds_get_packet2(). This is not surprising, because the correct-pts code
was changed to accept _complete_ packets, while all the old demuxers
(including the mpegts demuxer) require you to use "partial" packet
reads, together with the video_read_frame(). (That function actually
parses video frames, so fragments of the original "packets" can be fed
to the decoder.)

However, it returns out demux_ts packet's are mostly useable. demux_ts
still adds an offset (i.e. ds->buffer_pos != 0) to the packets when
calling internal parser functions, such as in parse_es.c. While this is
unclean design due to mplayer's old video demuxing/decoding path, it can
be easily be made work by modifying the packet as returned by
ds_get_packet2(). We also have to change the packet freeing code, as
demux_packet->buffer doesn't have to point to the start of the memory
allocation anymore.

MPlayer handles this "correctly" because it doesn't have a function that
reads a complete packet.
demux_lavf: workaround minor ffmpeg memory leak

The sequence of avcodec_alloc_context3() / avcodec_copy_context() /
avcodec_close() / av_free() leaks some memory. So don't copy the context
and use it directly.

Originally avcodec_copy_context() was used to guarantee that libavformat
can't update the fields of the context during demuxing in order to make
things a little more robust, but it's not strictly needed, and
ffmpeg/ffplay don't do this anyway. Still might make the situation worse
should we move demuxing into a separate thread, though.