Separation of Mercurial and Git library support

Since the beginning of the Heptapod project, the inner changes we've made to support Mercurial have been actually modifications to the Gitlab::Git::Repository class.

Since then (from GitLab 10.5 to 12.3), lots has happened:

• this Repository class has become upstream essentially a forwarder to Gitaly client classes
• we've moved our modifications into distinct methods (usually prefixed in hg_)
• we've introduced the vcs_type field on the Project model, had the various callers use it to dispatch to the appropriate methods.

At the point reached in Heptapod 0.12, we had a form of inner VCS independency (dual VCS support being a long term goal), but it was spread over.

This MR introduces the new Gitlab::Mercurial::HgGitRepository class, and use a classical factory pattern in the Repository model to dispatch according to the value of vcs_type, making many - but not all - calls effectively transparent for the callers.

At this point we can have a better confidence that Git code paths are untouched, which is essential for dual VCS support as well as for the introduction of HGitaly backed repositories, that don't rely on Git at all.

At the end of the series:

• the diff with upstream GitLab for Gitlab::Git::Repository boils down to accepting (and ignoring) optional arguments in the create method.
• in Gitlab::Shell (remnant of ancient times when operations on a repository as a whole where actually handled by GitLab Shell), the create method simply defers to the Repository model, slightly ahead of GitLab 12.3, and like it will in Gitlab 12.4

After this, there would still be some work to be done in Gitlab::Shell, to make repository moves (used in particular by the hash storage migration and rollback) and imports dispatch, but that's too much for Heptapod 0.13.0rc1