CI: limit scipy-openblas32 wheel to 0.3.23.293.2

[mattip]

I am working towards adding a scipy_ prefix to all the openblas symbol names in the scipy-openblas wheels. This will allow using both the scipy-openblas wheels and another OpenBLAS library together in scipy, for instance if using a scipy compiled with the "regular" OpenBLAS together with a numpy compiled with the OpenBLAS wheels.

In order to do an ordered transition, first this PR freezes the current version of scipy-openblas32 used in CI here. Then I will release new scipy-openblas32 wheels with an updated scipy-openblas.pc file, that will define a new -DBLAS_SYMBOL_PREFIX=scipy_ compile-time directive. Then I will come back to here and submit a new PR that reverts this one, and makes sure the use of BLAS_SYMBOL_PREFIX actually works.

[mattip]

xref @rgommers

[mattip]

Is there something wrong with the baseline support for numpy? I see this error in the meson 3.12-dev build

Error compiling Cython file:
------------------------------------------------------------
...

@cython.boundscheck(False)
@cython.wraparound(False)
cpdef void _categorize(cnp.float_t[::1] draws,
                       cnp.float_t[::1] p_cumulative,
                       cnp.int_t[::1] result) noexcept nogil:
                       ^
------------------------------------------------------------

/home/runner/work/scipy/scipy/scipy/stats/_sobol.pyx:409:23: 'int_t' is not a type identifier

[rgommers]

That build failure with the numpy nightly is due to the int_t removal in numpy, and being worked on in gh-19466.

[tylerjereddy]

Yeah, we're familiar with the two failing CI jobs. I just checked that all three locations where we use scipy-openblas32 have their respective CI jobs still passing in the matrix for this branch, so in it goes I think so you can move forward with the symbol work.