libquvi9: work around insane interaction between libquvi and libkdecore

The primary effect of this commit is that it fixes playback resume if
libquvi 0.9 and German locale are used, and libkdecore is on the system.
(See github issue #279.)

libquvi uses libproxy to determine system-wide proxy settings. libproxy
in turn loads libkdecore (if present) to determine KDE proxy settings.
libkdecore has a global constructor, which calls setlocale(LC_ALL, ""),
switching the current locale from "C" to what the user's settings. This
breaks some basic C string processing functions. Note that the locale
won't be set on program start, but only when libproxy calls dlopen() on
its config_kde module, which actually causes libkdecore to be loaded and
initialized.

In particular, with German locale, snprintf() would use "," instead of
"." when formatting float values, which in combination with playback
resume, would lead to parse errors the next time mpv was started, which
is how this issue was found.

I'd consider this a bug with libkdecore or at least libproxy. No library
should ever even touch locale: it might break basic expectations on C
string handling functions, might override program settings, and it's not
thread-safe. But this is so nasty and severe, that a quick hack to fix
it hurts less.

See github issue #279 and KDE bug #325902.

mpvcore/resolve_quvi9.c

@@ -17,6 +17,7 @@
 
 #include <stdbool.h>
 #include <assert.h>
+#include <locale.h>
 
 #include <quvi.h>
 
@@ -146,5 +147,11 @@ struct mp_resolve_result *mp_resolve_quvi(const char *url, struct MPOpts *opts)
         talloc_free(res);
         res = NULL;
     }
+
+    // libkdecore calls setlocale(LC_ALL, ""), which breaks basic C string
+    // processing functions. libkdecore can be loaded by libproxy, which is
+    // used by libquvi9. This is a rather dirty workaround to reset locales.
+    setlocale(LC_ALL, "C");
+
     return res;
 }