config: don't write default config file

This created an essentially empty config file. This is not really
needed and probably causes more trouble than it solves (such as
littering the home directory with crap), so get rid of it.
config: add a --config-dir option to force config directory

Useful for slave-mode like uses, and not as radical as --no-config.
manpage: remove unused environment variable

We removed gettext (which was disabled by default) a while ago.
config: always print resolved config paths in verbose mode

Restructure the code to make that easier. There should be no functional
changes, other than the log call at the end of each function.
input: allow input.conf bindings to be declared as builtin

This might be helpful if we ever want cascading config files. Also, we
will probably need it if we change the default input.conf bindings, and
want to provide compatibility input.conf files.
config: don't save options to resume-config that didn't change

This is approximate: we read each option value on program start
(before starting playback of a file), and when writing the resume
config, compare each value to the current state. This also means
when a value is changed and then changed back, it's not stored. In
particular, option values set in config files and on the command
line are considered the default.

This should help reducing the numbers of options overridden by the
resume config. If too much is overridden, it becomes an inconvenience,
because changes in config files will apparently have no effect when
resuming a file.

Also see github issue #574.
config: when writing resume config, read options, not properties

This lowers the number of data stored in the resume config a bit
further, because some properties can't be read at program start and when
e.g. the VO wasn't created yet.

Some fields still need to be read from a property (actually only
"volume-restore-data", a hack to save the full volume information). So
abuse the "options/" property, and make use of the fact that changing
things at runtime also changes the options.
client API: change description of format conversions

This changed during the time between writing the comment, and finishing
up the implementation.

Although I'm still unsure about this.
options: allow changing options at runtime

Allow changing all options at runtime, except some cherry-picked
options, which are disabled with M_OPT_FIXED.
osd: override user bindings for OSC input

E.g. binding MOUSE_BTN0 always used the user defined binding. While it
is ok that the user can override mouse_move and mouse_leave (for
whatever reasons), we want to strictly override the bindings when input
is sent to the OSC itself.

Regression since 03624a1.
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.