Add missing pip in $PATH on Cygwin CI

[EliahKagan]

This makes a pip -> pip3 symlink in /usr/bin in a new step prior to the first step that runs the pip command. Using pip3, pip3.9, or a command like python -m pip would work, but this allows the Cygwin workflow to continue using the same installation commands as the main testing workflow.

Adding this fixes two problems:

1. When the pip version installed by the python39-pip Cygwin package is current, so that upgrading pip doesn't install any new command, no pip command is created in /usr/local. This has happened not to be the case for a long time, which is why the Cygwin workflow was able to pass. (That the recent failures started at the merge of #1783 turns out to be a coincidence: rerunning jobs on prior commits has the failure, as does experimentally reverting it.)

2. Even when the pip version installed by python39-pip is behind the latest available version, pip is still used before being upgraded to check if setuptools is installed, to decide whether to upgrade it. This is to keep similar steps in the two testing workflows similar, since the Cygwin workflow only uses Python 3.9, which always has setuptools. Because pip was never in $PATH in that step, the Cygwin workflow wrongly refrained from trying to upgrade setuptools.

When the "Update PyPA packages" step does find a newer version of pip to upgrade to, it installs it in /usr/local/bin, which we have in $PATH before /usr/bin, so the upgraded version, when present, will still be preferred in subsequent commands, as before.

Running pip on Cygwin when it may not be in $PATH -- and, for one step, never is -- was a bug introduced in e8956e5 (#1709). Before that, pip still was not always available, but it was not used. This change fixes the bug by making sure pip is always available.

This pull request also changes setuptools detection to be more precise. It's fairly unlikely that the old way would have misdetected setuptools, but on Cygwin it was passing multiple setuptools arguments to pip install, which made no behavioral difference but made the GitHub Actions log confusing.

[Byron]

Thanks a lot for this fix!

And I thought it was just some upstream package that changed behaviour and broke CI, and would never have guessed that it was subtly introduced previously.