configure: fix typo

When using help, the output for --enable-shared was :
`--enable-shared     enable enable shared library [disable]`
m_option: fix printf format specifier
vo_opengl: Add :icc-approx-gamma suboption to approximate BT.709 gamma

This uses the value of 1.95 as an approximation for the exact gamma
curve, which replicates the behavior of popular video software including
anything in the Apple ecosystem, as per issue #534.
vdpau: change the error message when video too large
client API: spelling
client API: remove trailing "," from enums

This is allowed in C99 and C++11, but apparently not in C89 and C++98.

Make it conform to the older standards, since we want the client API
header to be highly portable.
client API: fix a typo
client API: change semantics for MPV_FORMAT_STRING

With mpv_set_property(h, "property", MPV_FORMAT_STRING, ptr), ptr now
has to be of type char** instead of char*. This makes it more consistent
with mpv_get_property() and also non-pointer formats, which will be
introduced in the following commits. mpv_set_property() of course does
not change its interface (only its implementation is adjusted to keep
its interface).

This also affects mpv_set_option(), but again not
mpv_set_option_string().
client API: add more data formats, add a structured data type

This adds declarations for new formats. The implementation will be added
in the following commits. (It still compiles and runs with this commit,
because it adds constants only.)

The obvious new types are MPV_FORMAT_FLAG, MPV_FORMAT_INT64,
MPV_FORMAT_DOUBLE. MPV_FORMAT_FLAG is a boolean, but to avoid nasty ABI
issues or with languages that don't have a bool data type (C89), it uses
int. Thus the format is not named MPV_FORMAT_BOOL, to avoid confusion.

The MPV_FORMAT_NONE type (mpv_node) is a generic structured type, like a
variant or, say, JSON. It can store strings/bools/numbers, as well as
arrays and key/value pairs (with string keys only).

The MPV_FORMAT_NODE_ARRAY and MPV_FORMAT_NODE_MAP types are used
internally by mpv_node only and can't be used with most of the other API
(like mpv_set_property()) directly.
m_property: simplify some code
client API: adjust error strings

These error codes can be used for setting and getting, not just for
settings (although currently there's no API to get options directly).
m_option: add a way to convert values to/from mpv_node

m_option is basically the mechanism to handle C data types in a dynamic
way. Add functions to convert values to and from mpv_node. For example,
string lists are turned into mpv_node using MPV_FORMAT_NODE_ARRAY, and
so on.
m_property: add mechanism to access properties as mpv_node

Allows retrieving properties by their native values (or something close
to it), rather than having to go through string conversion. The caller
could actually just copy the value itself and then use the m_option
functions to convert it to mpv_node, but maybe it's more flexible this
way.
client API: add support for accessing properties by their native type

This actually makes use of the client.h declarations and the mpv_node
mechanisms added some commits ago.

For now, using MPV_FORMAT_STRING will usually fallback to explicit
string conversion, but not in the other cases. E.g. reading a numeric
property as string will work, but not reading a string property as
number. Other than that, only MPV_FORMAT_INT64->MPV_FORMAT_DOUBLE does
an automatic conversion.

I'm not sure whether these semantics and API are good, so comments and
suggestions are welcome.
m_property: retrieve chapter lists etc. as mpv_node

This automatically allows accessing properties like chapter-list and
track-list to be read as mpv_node. This affects all properties which use
m_property_read_sub() and m_property_read_list().
client API: implement setting options using their native type too

This is only half-implemented: actually the option will first be
converted from mpv_node to its native type, then it's converted to a
string, and then back to its native type. This is because the option
API was made for strings and not anything else.

Other than being grossly inelegant, the only downside is probably with
string lists and key/value lists, which don't escape strings containing
syntax elements correctly.
lua: add a bunch of functions to get/set properties by their native type

There are some complications because the client API distinguishes
between integers and floats, while Lua has only "numbers" (which are
usually floats). But I think this should work now.
client API: add comment about character encoding issues

Also mention that NULL isn't valid. Although I'm not sure whether the
implementation strictly follows this (it should, but there are some
wacky corner cases).
command: make options property return the list of all options
lua, osc: use properties for chapter/track lists