Create new release when merge requests are merged into the
`$STABLE_BRANCH` branch.

* templates/Release/Semantic-release.yaml: run `semantic-release` with
  the latest EOLE container for `$STABLE_BRANCH` branch if one of its
  configuration is present.

* .gitlab-ci.yml: execute a new stage `release` for
  `semantic-release`.

* release.config.js: create `docs/CHANGELOG.md` and publish new
  releases on Gitlab.
  Mangle commits to have links for users, issues and commits id.

* release-rules.js: create semantic version update rules based on
  `docs/CONTRIBUTING.md`.

feat(rules): we prefer release naming over production status

See merge request !8

This make a better distinction between `stable` software and software
deployed in production.

We define 3 branches:
- `dev`: new developped features are integrated here, this is the
  default branch
- `testing`: is a fork of `dev` when we want to prepare the next
  release, this is the branch from where release bugfixes are derived
  and merged back
- `stable`: is where the `testing` branch is merged to produce a new
  release

ci(rules): define git-flow style rules

See merge request !7

We define rules to match somewhate a git-flow style workflow to
activate jobs:

- `.not-on-prod`: on all branches except production

- `.on-branches` : on supporting branches, i.e. everything except
  production and developpment

- `.on-dev`: on developpment branch only

- `.on-prod`: on production branch only

- `.on-release-tag`: on the release tag only

We always exclude pipeline triggered from schedule.

* templates/Rules.yaml: define the new rules templates.

* templates/Lint/Commitlint.yaml (commitlint): execute on all branch
  except production.

ci(commitlint): master is not always the repository default branch

See merge request !6

* templates/Lint/Commitlint.yaml (commitlint): use
  `$CI_DEFAULT_BRANCH` as base to calculate the list of commits to check.

ci(gitlab-ci): split in reusable templates

See merge request !5

This will permit other projects to
[include](https://docs.gitlab.com/ee/ci/yaml/#include) the defined
templates

The `templates/Rules.yaml` must be included and jobs will `extends`
the templates depending at which moment they must be executed.

ci(gitlab): add commit lint and its documentation

See merge request !2

* .gitlab-ci.yml: define only stage `lint` for now and run
`commitlint` at that stage.

* docs/CONTRIBUTING.md: describe the commit message formatting rules.

* README.md: link to the contributing guide.

ci(codeowners): define @EOLE group members as owners

See merge request !3

This permit to notify the group for reviewing merge requests.