Only callacks are tested by default. In order to test qt dialogs, run the test
manually with './test_src_interface_dialog -a'.

- vlc_dialog_wait_question will replace dialog_Question

- vlc_dialog_wait_question with i_type == VLC_DIALOG_QUESTION_CRITICAL and
  without action1/action2 will replace dialog_FatalWait

- vlc_dialog_wait_login will replace dialog_Login

- vlc_dialog_display_progress will replace dialog_Progress

- dialog_Fatal is replaced by vlc_dialog_display_error

- vlc_dialog_display_error will replace dialog_Fatal

- vlc_ext_dialog_update will repalace dialog_ExtensionUpdate

- vlc_dialog_wait_question and vlc_dialog_wait_login are interruptible via
  vlc_interrupt.

- Nothing prevents to have more than one dialog type displayed at a time.

It'll will be replaced by the new dialog API

Signed-off-by: Rafaël Carré <funman@videolan.org>

Debian dropped winepath /usr/bin symlink:
http://anonscm.debian.org/cgit/pkg-wine/wine.git/commit/?id=a778a9ba05d57fb6b969d3e21e3cc26e78dc672c

Modified-by: Jean-Baptiste Kempf <jb@videolan.org>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Signed-off-by: Felix Paul Kühne <fkuehne@videolan.org>

Fix #16195

This explicitly allows the server to return gzip or deflate
Content-Encoding.

This is not explicitly allowed for normal streams because
Content-Encoding breaks use of bytes ranges. Seeking offsets and size
would be in terms of the compressed stream. This would prevent VLC
demuxers from seeking or estimating duration.

The HTTP origin server can still return Content-Encoding in any case as
VLC does not explicitly forbid it (with Accept-Encoding: identity).
However in practice, servers will not perform opportunistic on-the-fly
compression.

deflate is handled by the inflate stream filter.
gzip is handled either by the inflate or decomp stream filter.

This handles deflate encoding or application/zlib type transparently.

(Note though that it fails to check and discard the application/zlib
 content-type from the underlying stream.)