client API: clarify pause/unpause events, modify core-idle property

Whether you consider the semantics weird or not depends on your use
case, but I suppose it's a bit confusing anyway. At this point, we keep
MPV_EVENT_PAUSE/UNPAUSE for compatibility only.

Make the "core-idle" property somewhat more useful in this context.
client API: improve mpv_observe_property docs

Document the "normal" behavior (if MPV_FORMAT_NONE is not used) first,
and then introduce MPV_FORMAT_NONE as exception.

The actual semantics didn't change in mpv; this is only clarification.
command: add cache-buffering-state property
player: remove unnecessary code

This part is already done by open_stream_async().
x11: disable various features when embedding the window
player: minor cosmetic change
stream_dvb: use stream_drop_buffers()
stream: change internal instead of external pos when dropping buffers

stream provides a read buffer (so even something like stream_read_char()
is very fast). This means the stream reads ahead by a few KBs, and
implies that the internal position (s->pos, which would match e.g. the
file position in stream_file.c), and the external position
(stream_tell()) can be different. stream_tell() shows how these are
related.

When dropping buffers, which happens on byte-level discontinuities with
a bunch of streams (including DVB), we should not change the position as
seen by the demuxer. On the other hand, the internal position is not
really meaningful, since these streams aren't seekable anyway. So just
change the code such that stream_drop_buffers() doesn't change the
demuxer visible position.

I'm hoping that this will fix a few problems with DVB. (Also see
previous commit.)
vf_lavfi: fix compilation failure

Apparently this fails to compile with clang6. Patch by someone else.

CC: @mpv-player/stable
msg: set an explicit overflow message

So client API users don't have to worry about this specifically.

Also document the overflow case. (Not sure if we really need to do
this; maybe it'd be better not to, since this just adds more noise
to the docs.)
msg, client API: never send the status line as log message

The status line is a bit special; for example it uses special control
codes by design and is not terminated with a newline character in order
to update it on the terminal without scrolling. It's not helpful for
client API users either, and would require special-casing them
(emulating aspects of a terminal?). Also, the status line code is
explicitly disabled on osd.c unless the --terminal option is enabled,
so there was no good way to even enable the status line for the API.

Just pretend that the status line does not exist as far as the client
API is concerned. It won't be sent as MPV_EVENT_LOG_MESSAGE.
msg, client API: buffer partial lines

The API could return partial lines, meaning the message could stop
in the middle of a line, and the next message would have the rest of
it (or just the next part of it). This was a pain for the user, so do
the nasty task of buffering the lines ourselves.

Now only complete lines are sent. To make things even easier for the
API user, don't put multiple lines into a single event, but split them.

The terminal output code needed something similar (inserting a prefix
header on start of each line). To avoid code duplication, this commit
refactors the terminal output so that lines are split in a single
place.
DOCS/client_api_examples: qtexample: add a log window

For the purpose of demonstration.

Also make the windows larger. I'm not exactly sure how Qt determines
the default window sizes, but here they are a bit tiny, so force them
larger.
client API: introduce numeric log levels

Maybe using strings for log levels was a mistake (too broad and too
impractical), so I'm adding numeric log level at least for the receiver
side. This makes it easier to map mpv log levels to other logging
systems.

I'm still too stingy to add a function to set the log level by a numeric
value, though.

The numeric values are not directly mapped to the internal mpv values,
because then almost every file in mpv would have to include the client
API header.

Coalesce this into API version 1.6, since 1.6 was bumped just yesterday.
msg: fix unwanted blank lines

Was broken in a commit earlier this day.
cocoa: allow to embed into an arbitrary NSView

Basically add if guards on all the problematic features. I'm still thinking
about a better way to handle this, but for the time being, this will do.
player: don't reset buffering pausing state on seeks

This was added with commit 3cbd79b3, but it turns out this
unintentionally enables "real" pausing when seeking while buffering. It
was done for ensuring correct state of the "cache-buffering-state"
property, but it also turns out that this was unneeded (another variable
that is reset when seeking happens to take care of this).
video: try harder to decode cover art picture only once

For cover art, we pretend that the video stream is infinite, but also
stop decoding once we have an image on the VO (this seems advantageous
for the case when strange filters are inserted or the VO image gets
lost). Since a while ago, the video chain started decoding 2 images
though ("Non-monotonic video pts: 0.000000 <= 0.000000"), which is
annoying and wasteful.

Improve this by handling a certain corner case at initialization, which
will decode a second image while the first one is still stuck in the
filter chain. Also, just in case there are filters which buffer a lot,
also force EOF filtering (which means we tell the filters to flush
buffered frames).

CC: @mpv-player/stable
vf_lavfi: proper rounding for lavfi->mpv aspect ratio

Or so I think. Not like it matters anyway.
client API: rename --input-x11-keyboard to --input-vo-keyboard

Apparently we need this for Cocoa too. (The option was X11 specific in
the hope that only X11 would need this hack.)