Document the release process in a file at the repository root (e.g. RELEASE-PROCESS.md)

[nbuffon]

1. We all agree that one version for all is not suitable
2. No version change in functional branches
3. Version changes have to be made in dedicated branches
4. When merging into master, check the diff to identify if any version has changed.
   If any, build and publish the new package at the new version; and a new git tag is created language.module-version
5. If at publish a package at this version already exists, the pipeline job must fail
6. Example are not published
7. Semantic tags (created manually): YYYYmmdd.HHMM-purpose
   E.g. 20241120.1212-Demo-5GLab
8. Version should follow the X.Y.Z form where X is major, Y minor, and Z fix (see https://semver.org/)
9. Create a new webpage (gh-pages)
10. Rust packages are published on crates.io; and documentation on docs.rs
11. Python packages are published on pypy.org; and documentation on readthedocs.com
12. Java packages are published on ?