sd_lavc: remove ineffective code

It makes no sense to set the packet duration, because libavcodec doesn't
know the timebase. And in fact, no subtitle decoder accesses the packet
duration, except text subtitle converters, which are not relevant here.
So this code did nothing - drop it.

Also fix a blatantly incorrect comment.
demux: avoid unnecessary wakeups

If a packet is appended to a stream, and there were already packets
queued, nothing about the state changed, as far as the user (i.e. the
player) is concerned. Thus no wakeup is needed.

The pthread_cond_signal() call following this is not interesting - it
will simply be a NOP if there are actually no waiters.
win32: correct HANDLE type

The correct type is HANDLE, not HANDLE*, though this change shouldn't
affect functionality.
win32: correct SGR sequence handling

This should get colour working again on the Windows console.

Fixes #1032.
demux: always use AVPacket

This is a simplification, because it lets us use the AVPacket
functions, instead of handling the details manually.

It also allows the libavcodec rawvideo decoder to use reference
counting, so it doesn't have to memcpy() the full image data. The change
in av_common.c enables this.

This change is somewhat risky, because we rely on the following AVPacket
implementation details and assumptions:
- av_packet_ref() doesn't access the input padding, and just copies the
  data. By the API, AVPacket is always padded, and we violate this. The
  lavc implementation would have to go out of its way to make this a
  real problem, though.
- We hope that the way we make the AVPacket refcountable in av_common.c
  is actually supported API-usage. It's hard to tell whether it is.

Of course we still use our own "old" demux_packet struct, just so that
libav* API usage is somewhat isolated.
vo_opengl: don't cut off feature list output
input: change verbosity of some message levels

For --input-test, print messages on terminal by default.

Raise message level for enabling input sections, because the OSC makes
this very extremely annoying.
options: compatibility hack for --slave-broken

Seems some programs were still relying on it. Whatever, it's not hard to
support.

CC: @mpv-player/stable
command: change OSD formatting of "speed" property

The "x   " prefix annoyed some users.
msg: allow duplicating a mp_log

Trivial; this is mostly just reindenting the normal codepath.
input: redo how --input-file is handled

Abandon the "old" infrastructure for --input-file (mp_input_add_fd(),
select() loop, non-blocking reads). Replace it with something that
starts a reader thread, using blocking input.

This is for the sake of Windows. Windows is a truly insane operating
system, and there's not even a way to read a pipe in a non-blocking
way, or to wait for new input in an interruptible way (like with
poll()). And unfortunately, some want to use pipe to send input to
mpv. There are probably (slightly) better IPC mechanisms available
on Windows, but for the sake of platform uniformity, make this work
again for now.

On Vista+, CancelIoEx() could probably be used. But there's no way on
XP. Also, that function doesn't work on wine, making development
harder. We could forcibly terminate the thread, which might work, but
is unsafe. So what we do is starting a thread, and if we don't want
the pipe input anymore, we just abandon the thread. The thread might
remain blocked forever, but if we exit the process, the kernel will
forcibly kill it. On Unix, just use poll() to handle this.

Unfortunately the code is pretty crappy, but it's ok, because it's late
and I wanted to stop working on this an hour ago.

Tested on wine; might not work on a real Windows.
coreaudio_device: fix overwriting of user input

Fixes #1030