client API: fix broken property/option functions

1. Cannot set option after initialized: it seems that this bug has
   existed since libmpv was introduced first. Maybe just a typo.
2. Crash when setting property with native format: mpv_set_property
   just causes a crash when using a native format. I found an invalid
   casting and fixed it.
3. Wrong error value for mpv_get_property: when an error occurred,
   mpv_get_property always returns wrong format error because every
   error for property except M_PROPERTY_NOT_IMPLEMENTED is just ignored.

Signed-off-by: wm4 <wm4@nowhere>

Closes pull request #593. Does not incldue the first fix, which was not
correct. The underlying bug will be fixed by a later commit.

Commit message extracted from pull request and slightly edited.
m_option: don't make "unset" string and string list return NULL strings

This is a bit weird: m_option_string types (i.e. char*) can be NULL. But
they're supposed to be treated just like empty strings. So don't make
the m_option_type.print function return NULL for these values. Returning
NULL would mean failure.

This didn't matter much before, but was quite visible through the client
API.
m_property: fix confused error code

This broke the client API.
client API: treat MPV_FORMAT_STRING differently in mpv_set_property

Always map MPV_FORMAT_STRING to setting property value directly through
M_PROPERTY_SET_STRING, instead of trying to go through
M_PROPERTY_SET_NODE.

This treats a direct MPV_FORMAT_STRING query differently from a
MPV_FORMAT_STRING wrapped in a mpv_node. This was already the case in
mpv_get_property(). The reason for all this is that mpv_node is supposed
to be the exact type, while a direct MPV_FORMAT_STRING goes through all
possible conversions.

Not sure if these semantics are good.
options: fix --list-options output

This was a bit damaged by commit f3c933e5.
client API: accept NULL as mpv_destroy() argument
client API: don't explode when destroying uninitialized mpv_handle
threads: fix wait time overflow check

When passing a very large timeout to mpthread_cond_timed_wait(), the
calculations could overflow, setting tv_sec to a negative value, and
making the pthread_cond_timed_wait() call return immediately. This
accidentally made Lua support poll and burn CPU for no reason.

The existing overflow check was ineffective on 32 bit systems. tv_sec is
usually a long, so adding INT_MAX to it will usually not overflow on 64
bit systems, but on 32 bit systems it's guaranteed to overflow. Simply
fix by clamping against a relatively high value. This will work until 1
week before the UNIX time wraps around in 32 bits.
client API: don't send MPV_EVENT_IDLE when not entering idle mode

For simplicity, this was sent before actually checking the idle
condition, which meant that we'd send it even of the idle loop is never
entered.
m_option: fix key/value list string conversion

Meh.
lua: implement mp.get_opt() in Lua

Will be more expensive if used very often, but it's probably ok.

Reduce the dependency of lua.c on MPContext a bit further.
m_option: make converting mpv_node to string always fail
lua: mark table values returned by get_property_native with their type

Lua doesn't distinguish between arrays and maps on the language level;
there are just tables. Use metatables to mark these tables with their
actual types. In particular, it allows distinguishing empty arrays from
empty tables.
lua: add set_property_native function

Probably completely useless, at least for now.

Also not very well tested, but initial test seems successful.
vo_opengl: Change the default icc-intent to relative colorimetric

This used to be absolute colorimetric, but relative colorimetric is a
saner default due to the arguments presented in issue #595.

A short summary: In general it doesn't affect much because our eyes
adapt to the white point either way, but if running in windowed mode it
would make the whites seem inconsistent/tinted. For fullscreen
projection it's also undesirable since it reduces the dynamic range
without much benefit (again, since our eyes adapt either way) and it
also breaks calibration against ambient lighting.

This shouldn't change much, since most profile types that aren't 3DLUTs
aren't capable of either of those transforms, and most displays are
calibrated against D65 (same as BT.709 source) either way.
vo_opengl: change gamma suboption to take a value

The previous version of the gamma suboption was pretty useless. It could
be used to disable delayed gamma enabling, which is a mechanism to avoid
having to adjust gamma in the shader by default.

Repurpose the suboption and allow setting an exact gamma value with it.
You can already override gamma with the --gamma option as well as the
gamma input property, but these use a weird curve to create the
impression of a linear perceived brightness change when changing the
value. This suboption now allows setting an exact gamma value.
command: format volume property as integer for OSD

The value range is 0-100, so fractional values don't make much sense.
But the underlying data type is probably float to avoid getting "stuck"
when doing small volume increments. So step this around and pretend it's
an integer just on display.
command: use the step size for "add volume" commands

The step argument for "add volume <step>" was ignored until now. Fix it.

There is one problem: by defualt, "add volume" should use the value set
with --volstep. This value is 3 by default. Since the default volue for
the step argument is always 1 (and we don't really want to make the
generic code more complicated by introducing custom step sizes), we
simply multiply the step argument with --volstep to keep it compatible.

The --volstep option should probably be just removed in the future.
Merge remote-tracking branch 'upstream/master'

Conflicts:
	player/client.c