CI/CD

This MR provides a new basis for automatic testing and continuous deployment.

The updated .gitlab-ci.yml makes use of the new gitlab permission model that was introduced with gitlab 8.12, making some of the previously necessary hacks obsolete.

The CI configuration currently defines two stages: test and release.

test Stage
This stage runs tests (currently just PEP8 using flake8) in a shared runner using a docker executor. Unit tests will be added later to this stage, once they are reasonably in shape again.

release Stage
Two jobs are defined in the release stage.

1. deploy-docker: This stage is optional, it has to be triggered manually. This stage uses a new Dockerfile to build a ready-to-deploy ramsis image and pushes it to the gitlab registry. Further details below.

2. deploy-production: This stage executes if the test stage has passed and if we're on a tagged master commit (i.e. a release). It deploys rt-ramsis to any gitlab-runners with the production tag. Currently there is one on ramis.ethz.ch.

Related Changes

requirements.txt
The various platform specific requirements files are reduced to a single requirements.txt to better conform to what a user would expect (having a single requirements.txt is pretty much standard). Egg version info was removed since this has been deprecated with pip 18.0. Gitlab-CI and the Dockerfile inject access credentials on the fly where necessary.

setup.py
Version specs were relaxed for dependencies to conform with best practices

Dockerfile
The Dockerfile deploys rt-ramsis to a container over three stages:

1. Stage 1: builder
   Builds wheels for all dependencies that are then copied to stage 2. This is done so that access credentials injected into stage 1 don't carry over to the deployment image.

2. Stage 2: base
   This image contains all the dependencies but not rt-ramsis itself. This image is useful for debugging, e.g. with an IDE that deploys the code on the fly.

3. Stage 3:
   Final production image with rt-ramsis installed.