… the CI (#4028)

After some debugging, I think I have found the potential root cause of
the flaky missing dependencies on MacOS. It is in the conda clone step
in which only conda packages are copied over but not pip (untracked)
files.

For example, in this failure example
https://github.com/pytorch/pytorch/actions/runs/4692698401/jobs/8318918238
had:

```
Source:      /Users/ec2-user/runner/_work/_temp/conda-python-3.9.12
Destination: /Users/ec2-user/runner/_work/_temp/conda_environment_4692698401
Packages: 58
Files: 0 <--- Nothing here
```

And it used `/Users/ec2-user/runner/_work/_temp/miniconda/bin/conda` as
reported by `which conda`. This conda is correct but old 4.12.0
(https://github.com/pytorch/test-infra/blob/main/.github/actions/setup-miniconda/action.yml#L15).

On the other hand, when working correctly, these files should have been
copied over to the cloned env:

```
Source:      /Users/ec2-user/runner/_work/_temp/conda-python-3.9.12
Destination: /Users/ec2-user/runner/_work/_temp/conda_environment_4683905314
Packages: 58
Files: 13010 <-- These files are copied over
```

This conda here was `/opt/homebrew/Caskroom/miniconda/base/bin/conda` on
M1 and `/usr/local/bin/conda` on x86_64.
Both are newer (23.1.0). It seems that **we unknowingly use the newer
system-wide conda on MacOS**, which is not part of the CI.

So the attempt fix here is to:

* Upgrade MacOS conda to
[23.1.0](https://repo.anaconda.com/miniconda/Miniconda3-py39_23.1.0-1-MacOSX-arm64.sh).
My theory is that the conda clone issue was fixed by this
conda/conda#11364
* Always use `/Users/ec2-user/runner/_work/_temp/miniconda/bin/conda` as
this is supposed to be the one controlled by the CI
* Check if the number of untracked files (pip dependencies) is 0. If it
is, reinstall pip requirements directly on the cloned conda environment

### Testing


https://github.com/pytorch/pytorch/actions/runs/4695636286/jobs/8338451917

* Use `/Users/ec2-user/runner/_work/_temp/miniconda/bin/conda`
* Use `conda 23.1.0`
* Files are copied correctly