Adapt the branching model to GtiLab

• In the commit a6ce34, the branching model described in http://nvie.com/posts/a-successful-git-branching-model have been adopred. It relies on the branches: master, develop, feature, hotfix and release.
• Later on, git repositories have been migrated to GitLab.
• The branching model can be simplified using the GitLab functionalities issues tracking and merge request as recommanded in http://doc.gitlab.com/ee/workflow/gitlab_flow.html.
• The branching model is based on two stable branches master and production.
• Each code modification (bug fix, improvement, ...) start with an issue.
• For each issue a feature branch is create. Its name starts with the issue number.
• When the code for the issue is finished, it is pushed in the master branch via a merge request. The merge request description has to contains the issues number (fixes #14 (closed), closes #67, etc.). The issue has to be closed and the branch has to be deleted when the merge request is accepted.
• When the master branch reach a point corresponding to a release, it is pushed in the production branch via a merge request.
• An hot fix start by an issue. It is prepared in a dedicated branch. Once ready the dedicated branch is push to the master via a merge request (conflict might be solved at that time). The hot fix branch is pushed to the production branch when the hot fix is working in the master branch. Then the hot fix branch is deleted.
• The script build_version.py contains options to create the feature, hot fix and release branches. These options are obsolete with the GitLab branching model and have to be removed.
• We have to keep the option to start the process creating a new release. However the git tag can be removed since it can be done using GitLab.