command: if playback position is unknown, make percent-pos unavailable

Before that, it just returned -1.

The print case is inconsistent with that, but I'll leave it for now,
because it's consistent with status line / show_progress behavior.
osc: check for availabillity of percent-pos instead of length

... to decide wether the seekbar should be enabled or not.
player: use more than 1/100 resolution for --term-osd-bar

If the terminal width is large enough the position marker jumps over
several characters because currently pos only increases in 1/100th steps.
player: handle the corner cases in --term-osd-bar correctly

With the old code and pos == width - 2 one character too many is drawn.
io/win32: move mp_attach_console to terminal-win.c

Why didn't I put it there from the start?
msg: print module prefixes even if message contains newlines

This makes

    mp_msg(x, y, "a\nb\n")

behave the same as

    mp_msg(x, y, "a\n")
    mp_msg(x, y, "b\n")

which is probably what one would expect. Before this commit, the "b"
line didn't have a prefix when using ths single mp_msg call.
msg: move special declarations to msg_control.h

While almost everything uses msg.h, the moved definitions are rarely
needed by anything.
msg: fix typo in comment
msg: add a mechanism to output messages to a ringbuffer

Until now, mp_msg output always went to the terminal. There was no way
to grab the stream of output messages. But this will be needed by
various future changes: Lua scripts, slave mode, client library...

This commit allows registering a ring buffer. A callback would be more
straight-forward, but since msg.c sits at the bottom of the lock
hierarchy (it's used by virtually everything), this would probably be a
nightmare. A ring buffer will be simpler and more predictable in the
long run.

We allocate new memory for each ringbuffer entry, which is probably a
bit expensive. We could try to be clever and somehow pack the data
directly into the buffer, but I felt like this wouldn't be worth the
complexity. You'd have to copy the data a bunch of times anyway. I'm
hoping that we can get away with using the ringbuffer mechanism for
low frequency important messages only (and not e.g. for high volume
debug messages), so the cost doesn't matter that much.

A ringbuffer has a simple, single log level. I considered allowing
--msglevel style per-prefix configuration for each ringbuffer, but
that would have been pretty complicated to implement, and wouldn't
have been that useful either.
msg: expose log level names
lua: allow scripts to snoop messages

Adds the following Lua function to enable message events:

    mp.enable_messages(size, level)

size is the maximum number of messages the ringbuffer consists of. level
is the minimum log level for a message to be added to the ringbuffer,
and uses the same values as the mp.log() function. (Actually not yet,
but this will be fixed in the following commit.)

The messages will be delivered via the mp_event() in the user script,
using "message" as event name. The event argument is a table with the
following fields:

    level: log level of the message (string as in mp.log())
    prefix: string identifying the module of origin
    text: contents of the message

As of currently, the message text will contain newline characters. A
message can consist of several lines. It is also possible that a
message doesn't end with a newline, and a caller can use multiple
messages to "build" a line. Most messages will contain exactly 1 line
ending with a single newline character, though.

If the message buffer overflows (messages are not read quickly enough),
new messages are lost until the queued up messages are read. At the
point of the overflow, a special overflow message is inserted. It will
have prefix set to "overflow", and the message text is set to "".

Care should be taken not to print any messages from the message event
handler. This would lead to an infinite loop (the event handler would be
called again after returning, because a new message is available). This
includes mp.log() and all mp.msg.* functions. Keep in mind that the Lua
print() function is mapped to mp.msg.info().
lua: use core log level names

When the Lua code was written, the core didn't have names for log levels
yet (just numbers). The only user visible change is that "verbose"
becomes "v", since this level had different names.
mpv.desktop: use %U in desktop file as we can open urls

Signed-off-by: wm4 <wm4@nowhere>
cache: reduce message spam

Output only 1 message every 5 seconds at most.
options: add key/value pair list option type
lua: add a --lua-opts option, which can be queried by scripts

The values set by this new option can be queried by Lua scripts using
the mp.getopt() function. The function takes a string parameter, and
returns the value of the first key that matches. If no key matches, nil
is returned.
cache: remove debug code

This was accidentally committed.

<rcombs> `mp_sleep_us(100000);` <-- are you drunk?
player: don't use OSD message stack for term OSD subs

Showing subtitles on terminal used the OSD message stack (which uses a
stack to "pile up" messages that were displayed at the same time). This
had a bunch of weird and annoying consequences. This accessed a certain
osd_state field, which is a minor annoyance since I want to make that
struct opaque. Implement this differently.
player: remove OSD stack

If certain OSD messages were displayed at the same time, the hidden
messages were put on the stack, and displayed again once the higher
priority messages disappeared. The idea was probably that lower priority
messages could not hide higher priority ones, and also that the lower
messages did not get lost.

But in practice, this gives confusing results with OSD messages randomly
reappearing for a brief time. Remove it.
player: remove OSD message IDs

These were needed before the last commit, but now they don't do anything
anymore. (They were used to decide whether to replace or stack the
previous OSD message when a new one was displayed.)