manpage: merge new manpage

About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.

Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.

Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.

Committers:

* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)

Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.

[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
man: remove documentation for deleted stuff

Also make some minor cosmetic changes.
man: update documentation related to screenshots
man: update man with vo_corevideo and vo_sharedbuffer

Conflicts:
	DOCS/man/en/vo.rst
Revert "codecs: prefer libmad over libmpg123"

This reverts commit c8b0f2115447f2fdd5bb8090d06153a4bf72d9ff.

This was a very bad idea. It caused A/V desync with some crappy AVI
files, and upon inspecting ad_mad.c, it seems all hope is lost.
Go back to the prefering the mpg123 & libav codecs.
AF: remove af_gate and af_comp

To quote the manpage: "This filter is untested, maybe even unusable."

And it seems they were never touched again after it was added many
years ago (except for cosmetic changes). Just get rid of them.
stream: remove stream_cue

stream_cue, which provided the cue:// protocol handler, was extremely
hacky and didn't even manage to play some samples I tried.

Remove it, because it's plain unneeded. There is much better support
for .cue files elsewhere:

- libcdio can play pairs of .cue/.bin files:

      mplayer cdda:// --cdrom-device=your_cue_file.cue

  Note that if the .cue file is not accompanied by a .cue file, but
  an encoded file for example, this most likely won't work.

- mplayer can play .cue files directly:

      mplayer your_cue_file.cue

  This works, even if the .cue file comes with encoded files that are
  not .bin . Note that if you play .bin files, mplayer will assume a
  specific raw audio format. If the format doesn't match, mplayer will
  play noise and destroy your speakers. Note that format mismatches are
  extremely common, because the endianness seems to be essentially
  random. (libcdio uses a clever algorithm to detect the endian, and
  doesn't have this problem.)
VO: remove VO direct rendering

This was disabled by default, and could be enabled with -dr. It was
disabled by default because it was buggy: there were issues with OSD
corruption.

It wasn't entirely sane for OpenGL based VOs either. OpenGL can chose
to drop mapped pixel buffer objects, requiring the application to map
and fill the buffer again. But there was no mechanism in mplayer to
fill the lost buffer again. (It seems this rarely happened in practice,
though.)

On the other side, users liked the --dr flag, because it promised them
more speed. I'm not sure if it actually helped with speed, but it's
unlikely it had any real advantages on modern systems.

In order to evade the --dr cargo culting in mplayer config files, it's
best to get rid of it.