docker: add Docker files for running an Apache mod_wsgi server

I frequently find myself wanting to run hgweb in a production-like
environment, with a real HTTP server and multiple WSGI workers.

This patch introduces a Docker environment for running Mercurial
under Apache + mod_wsgi. With just a few command executions, it is
possible to spin up a Docker container running hgweb.

The container is tailored for Mercurial developers wanting to run
Mercurial from a source checkout. It is **not** meant to be something
suitable for production use.

The container provides a default hgweb environment with an empty
repository that allows pushes. You can thus start a container and push
your favorite repository there for quick testing.

The container is designed to allow customizations. Users can provide
their own hgweb configurations and mount existing directories containing
repositories into the container.

The behavior of the container and how to control things is documented in
the README.rst file.

--HG--
extra : amend_source : db9dd77ac410fedef7bc07fbbdb1f69eb10184bf
merge: be precise about what merged into what in short desc

--HG--
branch : stable
extra : amend_source : 52368671d2ad901608a968ebb3e99a43b1cf71fc
manifest: fix a bug where working copy file 'add' mark was buggy

Because the same dictionary was used to (1) get node from parent and (2) store
annotated version, we could end up with buggy values. For example with a chain
of renames:

  $ hg mv b c
  $ hg mv a b

The value from 'b' would be updated as "<old-a>a", then the value of c would be
updated as "<old-b>a'. With the current dictionary sharing this ends up with:

    '<new-c>' == '<old-a>aa'

This value is double-wrong as we should use '<old-b>' and a single 'a'.

We now use a read-only value for lookup. The 'test-rename.t' test is impacted
because such a chained added file is suddenly detected as such.

--HG--
branch : stable
extra : rebase_source : 1307dec8508b449d295fb394c0f95f8bb1102439
rename: properly report removed and added file as modified (issue4458)

The result of 'hg rm' + 'hg rename' disagreed with the one from
'hg rename --force'. We align them on 'hg move --force' because it agrees with
what 'hg status' says after the commit.

Stopping reporting a modified file as added puts an end to the hg revert confusion in this
situation (issue4458).

However, reporting the file as modified also prevents revert from restoring the copy
source. We fix this in a later changeset.

Git diff also stop reporting the add in the middle of the chain as add. Not
sure how important (and even wrong) it is.

--HG--
branch : stable
extra : rebase_source : db1e7264ea35a336115141058381e230f9286542
revert: look for copy information for all local modifications

Renaming a file over an existing one marks the file as modified. So we
track rename source in modified file too.

--HG--
branch : stable
extra : rebase_source : f17d94a6d90dee4ef1c80571d40f985a26824dc9
merge with stable