* BUILD: update OpenBLAS to 0.3.21 and clean up openblas download test

* set LDFLAGS on windows64 like the openblaslib build does

* use rtools compilers on windows when building wheels

* fix typos

* add rtools gfortran to PATH

* use the openblas dll from the zip archive without rewrapping

* typos

* copy dll import library for 64-bit interfaces

* revert many of the changes to azure-steps-windows.yaml, copy openblas better in wheels

* fix wildcard copy

* test OpenBLAS build worked with threadpoolctl

* typos

* install threadpoolctl where needed, use for loop to recursively copy

* update macos OpenBLAS suffixes for newer gfortran hashes

* use libgfortran5.dylib on macos

* fix scripts

* re-use gfortran install from MacPython/gfortran-install on macos

* use pre-release version of delocate

* fixes for wheel builds/tests

* add debugging cruft for pypy+win, macos wheels

* add DYLD_LIBRARY_PATH on macosx-x86_64

* use 32-bit openblas interfaces for ppc64le tests

* skip large_archive test that sometimes segfaults on PyPy+windows

Remove reference to Visual Studio version required by old versions
of Python. Python >= 3.5 is built with Microsoft Visual C++ 14.0 /
Visual Studio 2015:
	https://wiki.python.org/moin/WindowsCompilers

Numpy extensions define the extra_cxx_compile_args and extra_c_compile_args
filed, but distutils extensions don't. Take that into account when populating
build_extension.

Should fix #20928

In SciPy we had a couple of cases where we build a Python extension
with C source files but linked against static libraries built from
Fortran code. Those should be using the Fortran linker, but this
was broken in 1.22.0 by gh-19713 (the PR that introduced C++ in NumPy).

This fixes a few issues in the `build_ext` command, and documents better
what is going on there.

Should close SciPy issues 8325 and 15414.

We would like to extend CPU feature detection infrastructure
for IBM Z CPU features. Eventually It will help to add and
enable Z specific SIMD builtins and instructions.
As part of the PR, we have extended ccompiler_opt.py,
npy_cpu_features.c.src, npy_cpu_features.h, other files for
Z CPU feature detection and added test files for VX/VXE/VXE2
in distutils/checks.

At the moment, we are guessing whether we have the MSVC compiler, by
looking at what Python was originally compiled for.  That works only if
we are using the same compiler, but this is not the case when we compile
with e.g. mingw-w64 using Python.org Python.

Unfortunately, at the time we are specifying build flags, we don't know
what compiler we are using.

Allow build flags to clib to be callables that return lists of strings,
instead of strings, where the callables can do work like inspecting the
compiler, at build time.

Use this to check for MSVC at build time, when specifying the
`/GL-` flag.

See gh-9977 for a related discussion about these flags.

This is just a technical prototype to measure and discuss the impact and
implication of moving to C++ for kernel code generation.