mp_core: declare seek_type enum outside of nested struct

cosmetic change. See previous commit.
m_option: make "add speed 0.1" command work

Was broken since the speed property was switched from float to double.
vf_eq: fix behavior when changing parameters

Using -vf eq and changing brightness, contrast, etc. using key bindings
with e.g. "add brightness 1" didn't work well: with step width 1, the
property gets easily "stuck". This is a rounding problem: e.g. setting
gamma to 3 would actually make it report that gamma is set to 2, so
the "add" command will obviously never reach 3 with a step width of 1.
Fix this by storing the parameters as integers.

This was broken in cac7702. This commit effectively changed these
properties to use the value as reported by vf_eq, instead of the
previously set value for the "add" command. This was more robust,
but not very correct either, so we keep the new behavior and make
vf_eq report its parameters more accurately.
command: simplify video brightness/gamma/etc. handling a bit

We don't need to store the offsets of the options corresponding to the
properties, because the option-property bridge knows about this already.

The check against 1000 was for the case if e.g. the --brightness option
is not used. Always overwrite the option value instead, both when
querying and setting the property. (This is needed to make the settings
persistent even if vf_eq is used and the video chain is reinitialized.)

This commit assumes that VFCTRL_SET_EQUALIZER is always paired with
VFCTRL_GET_EQUALIZER (likewise for VOCTRL), which is the case.
manpage: fix (again) incorrect ao_alsa example

One example in ao.rst used the old syntax with misspelling of "no-block".
mplayer: start track IDs from 1 rather than 0

Completely pointless, but makes ChrisK happy for some reason.

Track ID 0 is now rejected by the option parser itself.
options: replace --edition=-1 with --edition=auto

Originally, the objective of this commit was changing --edition to be
1-based, but this was cancelled. I'm still leaving the change to
demux_mkv.c though, which is now only of cosmetic nature.
mplayer: replace "D:" in status line with "Late:"

Too many people thought "D:" really meant number of dropped frames. But
it's actually the number of frames where the playloop thought it'd be
a good idea to drop them. Of course this does nothing if frame dropping
is disabled, but even with normal frame dropping, this doesn't indicate
whether a frame was _really_ dropped. (Looks like libavcodec doesn't
even give us this information reliably? The decode function can return
no frame in case of codec delay due to threading and such.)
cocoa_common: fix window positioning with `--geometry`

Regression since ff3b98d11c. The window positioning code relied on the
visibleFrame's height without taking into account the dock's presence.

Also moved the constraining code to the proper method that overrides the
original NSWindow behaviour. This avoids having to check for border since the
constraining is performed by Cocoa only for titled windows.

Fixes #190
mp_msg: fix typo in message level for new msg API macros
video: add vda decode support (with hwaccel) and direct rendering

Decoding H264 using Video Decode Acceleration used the custom 'vda_h264_dec'
decoder in FFmpeg.

The Good: This new implementation has some advantages over the previous one:

 - It works with Libav: vda_h264_dec never got into Libav since they prefer
   client applications to use the hwaccel API.

 - It is way more efficient: in my tests this implementation yields a
   reduction of CPU usage of roughly ~50% compared to using `vda_h264_dec` and
   ~65-75% compared to h264 software decoding. This is mainly because
   `vo_corevideo` was adapted to perform direct rendering of the
   `CVPixelBufferRefs` created by the Video Decode Acceleration API Framework.

The Bad:
  - `vo_corevideo` is required to use VDA decoding acceleration.
  - only works with versions of ffmpeg/libav new enough (needs reference
    refcounting). That is FFmpeg 2.0+ and Libav's git master currently.

The Ugly: VDA was hardcoded to use UYVY (2vuy) for the uploaded video texture.
One one end this makes the code simple since Apple's OpenGL implementation
actually supports this out of the box. It would be nice to support other
output image formats and choose the best format depending on the input, or at
least making it configurable. My tests indicate that CPU usage actually
increases with a 420p IMGFMT output which is not what I would have expected.

NOTE: There is a small memory leak with old versions of FFmpeg and with Libav
since the CVPixelBufferRef is not automatically released when the AVFrame is
deallocated. This can cause leaks inside libavcodec for decoded frames that
are discarded before mpv wraps them inside a refcounted mp_image (this only
happens on seeks).
For frames that enter mpv's refcounting facilities, this is not a problem
since we rewrap the CVPixelBufferRef in our mp_image that properly forwards
CVPixelBufferRetain/CvPixelBufferRelease calls to the underying
CVPixelBufferRef.

So, for FFmpeg use something more recent than `b3d63995` for Libav the patch
was posted to the dev ML in July and in review since, apparently, the proposed
fix is rather hacky.
stream_file: uncrustify
stream_avdevice: remove redundant dummy callback
stream: move file forward skipping to common stream implementation

stream_file.c contains some code meant for forward seeking with pipes.
This simply reads data until the seek position is reached. Move this
code to stream.c. This stops stream_file from doing strange things
(messing with stream internals), and removes the code duplication too.

We also make stream_seek_long() use the new skip code. This is shorter
and much easier to follow than the old code, which basically did strange
things.
stream: don't require streams to set s->pos in seek callback

Instead, set s->pos depending on the success of the seek callback.
stream: allow potentially faster skipping

Instead of always skipping in STREAM_BUFFER_SIZE blocks, allow an
arbitrary size. This allows - in theory - faster forward seeking in
pipes.

(Maybe not a very significant change, but it reduces the number of
things that depend on STREAM_BUFFER_SIZE for no good reason. Though
we still use that value as minimum read size.)
demux_raw: read multiple frames per packet

The rawaudio demuxer read one frame per packet, basically a few bytes,
which caused insane overhead. (I found this when I couldn't play raw
audio without dropouts when using -v, which printed a line per packet
read.)

Fix this and read 1 second of audio per packet. This is a regression
since cfa5712 (merging of demux_rawaudio and demux_rawvideo).
demux: check whether stream is selected in demux_get_next_pts()

Otherwise, this would just try to demux a good chunk of the file, even
though the operation can't succeed anyway.

This caused some pretty strange issues, where perfectly valid use cases
would print a "Too many packets in the demuxer packet queue..." message.
demux: remove unused audio_delay parameter from demux_seek()

Used to be needed by demux_avi.
ao: remove some leftovers