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 agree with having CI bump the dependency versions. I think we can start with a `environment-latest.yml` with pinned direct conda and pip dependencies. I wouldn't go with lock files just yet since they are platform specific. 

We also need to have the minimum dependencies be in sync with [_min_dependencies.py](https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/_min_dependencies.py).

The complexity comes from each CI uses a different combination of min and latest dependencies. For example, `py37_conda_defaults_openblas` uses the minimum versions of `numpy` and `scipy` but the latest version of pytest-xdist.  In the end, we'll likely end up something like [dask/continuous_integration](https://github.com/dask/dask/tree/main/continuous_integration) but with more pinning. There will be a different `enivornment.yml` file for each runner and we have CI update the dependencies. 

As for contributing docs, I'll want one CI instance to use `environment-latest.yml` and another using `requirements-latest.txt` for testing. That way the contributing docs can say

```
pip install -r build_tools/requirements-latest.txt

# or

conda env create -f build_tools/environment-latest.yml
```

Since we test them, we know the dependencies work and it becomes one line to install all the development dependencies.

Labels: Build / CI