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.