Pin dependencies version in CI with lock files with a bot that auto-updates the lockfiles

### Motivation

- avoid CI breakage due to dependencies updates (recent examples: setuptools update, pytest7 update, coverage 6.3 update, very likely others ...)
- avoid painful debugging when a breakage happens to figure out what is the cause of the problem and generally end up after some time that a dependency has changed
- avoid breaking everyone PRs which is confusing for contributers

### Ideas for implementation

- have environment.yml files for each build rather than versions defined in azure/Circle .yml (for the build using build, we can either use  poetry or conda-lock is supposed to support pip section in the environment.yml although I have not managed to get it to work yet)
- have a script using [conda-lock](https://github.com/conda-incubator/conda-lock) to regenerates conda lock files for each build based on their environment.yml
- have a bot that runs this script updates the lock files and creates a PR, it seems like using an approach using GH action like  Hypothesis does could work:
  https://github.com/HypothesisWorks/hypothesis/commit/c96bbc86efbaa46a78bbb075a36869734dde76b9.
- Have this PR merged if CI passes
- only one PR opened at a time to avoid generating many PRs with the same diff. If there is already an open PR (based on a github label for example), push -f  to the PR branch

### Where to start

I'll probably try out this idea on one build first (e.g. one using conda-forge) to test it out, see how that works, and go from there.

cc @thomasjpfan in case you have some thoughs about this or you have already started working on something similar

### Rejected alternatives

In an ideal workd we would "just" use Dependabot but [it can spam forks](https://github.com/dependabot/dependabot-core/issues/2804) with PRs. Numpy has given up on it see for example [this](https://twitter.com/ralfgommers/status/1457023221841149955)

COMMENT:
I bumped into SciTools/iris which seems to have bot that updates conda-lock lock files with a similar setup as ours:
- [workflow that updates lock files](https://github.com/SciTools/iris/blob/main/.github/workflows/refresh-lockfiles.yml) with the [actual code for the action](https://github.com/SciTools/workflows/blob/main/.github/workflows/refresh-lockfiles.yml) that uses https://github.com/peter-evans/create-pull-request to open a PR
- [Their doc to update lock files](https://scitools-iris.readthedocs.io/en/latest/developers_guide/contributing_ci_tests.html#github-actions-test-environment). In particular if the CI in the PR fails, it is up to a developer to take over in a separate PR and fix potential issues
- [examples of PRs created by the bot](https://github.com/SciTools/iris/pulls?q=is%3Apr+sort%3Aupdated-desc+CI+bot)
- [An example where the bot PR fails](https://github.com/SciTools/iris/pull/5185) and a developer opened a [new PR fixing the issue](https://github.com/SciTools/iris/pull/5188). Apparently with their setup you need to open a separate PR because the next time the bot updates its PR it erases any change you make to its PR branch. I think this is OK.

Labels: Build / CI