Dynamic environments aka review apps

This issue describes dynamic environments implementation, mostly to be used with dynamically create applications. These application will be mostly used for Review Apps.

Assumptions

1. We will allow to create dynamic environments from .gitlab-ci.yml, by allowing to specify environment variables: review_apps_${CI_BUILD_REF_NAME},
2. We will use multiple deployments of the same application per environment,
3. The URL will be assigned to environment on the creation, and updated later if necessary,
4. The URL will be specified in .gitlab-ci.yml, possibly introducing regexp for getting an URL from build log if required,
5. We need some form to distinguish between production/staging and review app environment,
6. We don't try to manage life cycle of deployments in the first iteration, possibly we will extend a Pipeline to add jobs that will be responsible either for cleaning up or removing old deployments and closing environments.

Configuration

    review_apps:
         environment:
              name: review/$CI_BUILD_REF_NAME
              url: http://$CI_BUILD_REF_NAME.review.gitlab.com/

Remarks

1. We are limited to use only CI predefined variables, since this is not easy task to pass the URL from build,
2. I do prefer nested url: since this allows us in the future to extend that with more environment: configuration or constraints, like: required_variables: or access_level of user allowed to use that.
3. Following the problem from (1) we can extend url: with a regexp that will be used to fish a URL from build log.

Distinguish between production and review apps

I feel that we need to be forward thinking and make this distinction. I thought about:

1. Introducing a predefined Environment Types: production, pre-production, staging, review,
2. Introducing a user configured Environment Types, similar to previous, but with full fledged management,
3. @markpundsack proposed to do use Stages of Pipeline to mark environment type,

But all of this doesn't feel right. So I thought that we should follow a principle: convention over configuration.

Convention over configuration

We would expect the environments to be of type/name:

1. This would allow us to have a clear distinction between different environment types: production/gitlab.com, staging/dev, review-apps/feature/branch,
2. Since we use a folder structure we could group all environments by type and strip that from environment name,
3. We would be aware of some of these types and for example for review-apps show them differently in context of Merge Requests, ex. calculating deployed ago a little differently.
4. We could easily group all types across from group from all projects.

The type/name also plays nice with Variables and Runners, because we can limit their usage:

1. We could extend the resources with a field that would allow us to filter for what types it can be used, ex.: production/* or review-apps/*
2. We could limit runners to be used only by review-apps/*,