Merge branch 'beta' into 'main'

feat!: v4

# v4.0.0

in the past months I have been struggling more and more with:
- kaniko in monorepos with multiple images
- python-semantic-release breaking all the time (master is broken because of that)
- our lack of modularity in tests (see efforts in !69)
- our lack of modularity in pipelines with projects that needed automation without being specifically a python project

I think several breaking changes are necessary to sort this out. I'm working in a branch `beta` on which semantic-release is kind enough to provide beta releases by default (after changing the current workflow behaviour).

## Changes

### Fixes

* [x] fix(python jobs): uses `pip install . || true` to either install package or not without breaking.
* [x] fix(workflow)!: changes behaviour to run always except for MRs. Running in branches is better than running in MRs because protected variables are available in protected branches but not in MRs of protected branches. This breaks semantic-releases for branches other than master/main (which is desirable for prereleases). I don't see advantages in running in MRs. If there are, we can allow MRs>branches for not protected branches with no open MRs.
* [x] fix!: removes deprecated jobs (...)
* [x] fix!: moves most rules out of jobs and into pipelines
* [x] fix(python jobs)!: declares image as global variable to allow for easy override in pipelines. 
* [x] fix(kaniko)!: improves kaniko by moving the behaviour from its script to the rules. Job comes with sane defaults destinations and no rules. Rules are provided in the `pipelines/docker.yml`. Pipelines and tests are updated accordingly. Notable changes:
  - always pushes to 2 destinations (by default same image with different tag).
  - `DEV_TAG`: `dev` images are back and are always produced for each commit on any branch. When image is required at next stage, the `dev` image should be used. dev tags are `dev-commit_short_sha`, which allows registry cleanup policy.
  - `KANIKO_TAG`: used for `latest`, `tags` and branches. These happen conditionally and defaults are set through rules in the `pipelines/docker.yml`. Rules follow the previous behaviour, but the tag format is different for branches (now `branch-${branch-name}), which enables registry cleanup policy.
  - variables have been renamed and moved for the most to global variables, for easy override in the pipelines.
  - handling directly KANIKO_REGISTRY_IMAGE and the tags allows much simpler overrides than with the previous `destinations` setup. This makes life much simpler in monorepo projects, especially if in combination with child pipelines.
* [x] fix!: removes python-semantic-release. I don't want to use this anymore as it is broken more often than it works.
* [x] fix!: removes python-basic / python-pro distinction. All python jobs of pro are now run, always. If user does not need/want them he can manually disable them with `rules when:never`. Our mileage may vary, but as we go towards standardisation I want to keep the bar high.
* [x] fix!: removes all poetry jobs, I don't want to maintain these in the future as I don't see the added value of poetry specific jobs. People should stick to the default `templates/python.yml` which will work fine if they are building a `setuptools`/`pep518` compliant package.
> "Any customer can have a car painted any color that he wants so long as it is black."
* [x] fix!: moves and renames `flawfinder` to python directory since it's a python package.
* [x] fix!: change images to the new https://gitlab.com/just-ci/images
* [x] fix: created https://gitlab.com/just-ci/utils. This is where we store and version things like the default gitlab settings and the semantic-release gitlab settings that we then pull in jobs if necessary. I thus moved the yaml file used by the `gitlab:recommended` job there and changed the url. I use this same trick for the new job `semantic-release:find-next`.

### Features
* [x] feat: templates. Templates = collection of pipelines + workflow & project automation. Users should import these and avoid importing pipelines directly. They make testing simpler (we don't have to suppress all the project automation jobs in our child pipelines) and offer an extra layer of customisation.
* [x] feat(project-automation): new jobs category with pipeline. We put all jobs that automate projects lifecycle (semantic-release, gitlab etc).
* [x] feat: templates. Highest level interface with the user. Templates import and combine pipelines. Users should import templates, not pipelines. separating templates and pipelines makes them easy to test (templates provide workflow and project-automation jobs which are a pain to deal with in testing, pipelines do not).
* [x] feat: adds `tbump` job. tbump just bumps files. nothing more.
* [x] feat: adds `check-GL-token` job in `.pre` to inform users of GL-token availability. This takes into account branch protection (variable should be available only in protected branches). If token not available (not set or not in protected branch) jobs that need it will not run (and thus not fail). If token available in non protected branch, jobs continue but user is alerted (exit code 1 + allow failure=true).
* [x] feat: adds `project-automation` pipeline with tbump + semantic-release & and all other project automation jobs. This is a universal setup and supports repositories of any kind. tbump requires a `pyproject.toml` or a `tbump.toml` to work, so it won't appear if these files are not present.

### Other

* [x] test: expands coverage and improves test organisation with child pipelines
* [x] test: skips most tests in tags
* [x] docs: update readme
* [x] define better failure defaults. security jobs have often false positives (allowing for a loose definition of positive) for example, it could be an idea to allow failure of bandit, safety and grype. We could then have another template that is strict for when it's necessary (when?)

See merge request just-ci/templates!1