Refer to "main branches" rather than "master"

Using `master` to refer to the main branch is not accurate:
1. some projects already have transitioned to `main`
2. mainy projects use multiple release-specific branches anyway,
   like `apertis/v2023dev1`, `apertis/v2022`, etc.

Signed-off-by: Emanuele Aina <emanuele.aina@collabora.com>

content/guides/development_process.md

@@ -133,7 +133,7 @@ Clone the forked repository
   cherry-pick or merges, those should go through merge requests as well:
   however, only changes related to the backport process are allowed, unrelated
   changes should be applied with a separate merge request, possibly landing in
-  master first.
+  the main branch first.
 
 
 ## Release Commits

content/guides/version_control.md

@@ -31,9 +31,9 @@ good working knowledge of git; some introductory material is available
 For projects where Apertis is the upstream developer, the git repositories
 follow these rules:
 
-- No forced pushes.
+- No forced pushes to main branches.
 - Rebase commits rather than merging.
-- Work on feature branches on Apertis git, then rebase on master and
+- Work on feature branches on Apertis git, then rebase on the main branch and
   fast-forward merge the changes.
 - Hide
   [sausage making](https://sethrobertson.github.io/GitBestPractices/#sausage)

content/policies/contributions.md

@@ -410,7 +410,7 @@ to be signed off by someone who takes responsibility for the open source
 licensing of the code being contributed. The aim of this is to create an
 auditable chain of trust for the licensing of all code in the project.
 
-Each commit which is pushed to git master **must** have a `Signed-off-by` line,
+Each commit which is pushed to the main branches in git **must** have a `Signed-off-by` line,
 created by passing the `--signoff`/`-s` option to `git commit`. The line must
 give the real name of the person taking responsibility for that commit, and
 indicates that they have agreed to the