ci: Runs triggered by dependabot PRs fail when using private repos as dependency

[llucax]

What happened?

We are seeing failures in PRs created by dependabot when private repositories are used as dependency because the PR doesn't have access to the secrets needed to fetch those dependencies.

What did you expect instead?

The PRs to be able to fetch the dependencies.

Affected version(s)

No response

Affected part(s)

Build script, CI, dependencies, etc. (part:tooling), Cookiecutter template (part:cookiecutter), Tools to configure the CI (part:ci)

Extra information

The problem started when GitHub decided to run dependabot created PRs without access to secrets](https://github.blog/changelog/2021-02-19-github-actions-workflows-triggered-by-dependabot-prs-will-run-with-read-only-permissions/). This was done to avoid security issues when updating dependencies, as when dependencies are installed, code from the dependencies is ran, so if someone took over the repo of a dependency and dependabot tries to upgrade and runs you CI with the secrets, the person that hacked the dependency repo will gain access to your secrets

We had an attempt at fixing this by configuring the GitHub organization to [allow dependabot access to the private repositories][dependabot-access], but that actually only affects the dependabot while searching for dependency updates, not when running the PRs workflows, so that doesn't work.

To fix this for good, we'll need a more complicated solution.

First, to make it work, we need to use the trigger: pull_request_target, which has access to the secrets, but will run on the base branch, not the PRs merge, so it won't have the dependency updates.

To make that work, we need to explicitly checkout the PRs merge in the action/checkout by using ref: ${{ github.event.pull_request.head.sha }}, but then we end up in the original security issue GitHub was trying to avoid when doing this change. But if we do this change for the general CI workflow, then it won't work when triggered by push, so we probably need to split it into a dependabot workflow and a regular CI workflow, using different triggers.

To make it secure we should somehow pre-install the private dependencies using the credentials first, and then fetch the rest of the (untrusted) dependencies without access to the secrets or GitHub workflow token. This would actually be the ideal for both the dependabot workflow and the regular CI workflow, as when dependencies are not pinned (like when we test with pytest_max, we'll also be installing the "latest" dependency, which might have been compromised).

Also we might want to completely avoid the pull_request_target trigger and instead split dependabot PRs CI in 2 steps.