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.
manpage: fix (again) incorrect ao_alsa example

One example in ao.rst used the old syntax with misspelling of "no-block".
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
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.