Document the deployment process

[Tracker]
Update Summary: [One-line status update for stakeholders]
Short Description: [One-line issue summary for stakeholders]
Check-in Date: MM/DD/YYYY
Metadata is used by the AI Tracker. Docs and additional fields here.
[/Tracker]

Problem/Motivation

Currently we have a problem that the releases are to dependent on one person and that the same person that creates a release is the one that verifies and publishes it.

We should:

1. Add at least two persons that has rights to prepare a release.
2. Add two other persons that can verify and publish a release.

Our normal patch release cycle we should release every second Wednesday in the evening CET.

This means that we can have merge stop Tuesday night CET, then have a release prepared before 10 CET to handover to the the person who publishes it and possible QA if needed. And then the publisher when verified, can release the package at 16-20 CET.

A security release is not that different, with the the main difference being that the security issue is pre-published as a security release and then its published by the security team.

Outside of that we have minor and major releases, that up until know doesn't have a structured release cycle or way of doing it, more than that it has a lot more manual testing around it. We need to structure this as well.

This needs to be documented, so any of the four persons can be replaced at any time, just by giving the right permissions.

Proposed resolution

* Document all the steps needed to create a release.
* Document all the steps needed to publish a normal patch release.
* Document all the steps needed to publish a normal minor or major release.
* Document all the steps needed to publish a security release.
* Document the people that is currently in charge of it.