Windows threading fix

[mattip]

• I updated the package version in pyproject.toml and made sure the first 3 numbers match ./openblas_commit.txt. If I did not update ./openblas_commit.txt, I incremented the wheel build number (i.e. 0.3.29.0.0 to 0.3.29.0.1)

Note: update ./openblas_commit.txt with cd OpenBLAS; git describe --tags --abbrev=8 > ../openblas_commit.txt

Create a separate queue for each thread on windows. Fixes #283

[mattip]

@yadonpapa could you download the wheels-x64-1 artifact, unzip it, copy it over the current libscipy*.dll in your numpy env, and run the test?

[yadonpapa]

Tested the wheels-x64-1 artifact from this PR (scipy_openblas64-0.3.34.237.2-py3-none-win_amd64.whl) on a second machine, with the DLL copied over numpy.libs\libscipy_openblas64_-*.dll of a fresh numpy 2.5.4 env (Python 3.12). openblas_get_config() reports OpenBLAS 0.3.34.237.2 USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell MAX_THREADS=24, 20 threads.

Machine: Windows 11 Pro 10.0.26200 x64, Intel Core i7-12700 (20 logical CPUs, Haswell kernels selected).

NumPy reproducer from numpy/numpy#27989 (gemm (N,3) @ (3,3) + gemv (N,3) @ (3,) in each thread, N random in 1,000..270,000):

DLL	threads	duration	result
stock 0.3.34.106.0 (numpy 2.5.4)	2	30 s × 3	crash 0xC0000005 after 1.6 s, 0.8 s, 0.4 s
PR 284 0.3.34.237.2	2	30 s × 3	no crash (≈19,000 iterations per run)
PR 284 0.3.34.237.2	4	60 s	no crash (49,092 iterations)
PR 284 0.3.34.237.2	8	60 s	no crash (54,159 iterations)

C reproducer from #283 (repro.exe <dll> 30 both, MSVC 19.5x, 3 runs each):

DLL	result
stock 0.3.34.106.0	crash after 0.3 s, 0.2 s, 0.1 s
PR 284 0.3.34.237.2	no crash, no crash, no crash

Results are also correct: 18,034 threaded products from 4 Python threads (default thread count) compared bit for bit against the same products computed with openblas_set_num_threads(1), 0 mismatches.

So the PR fixes it here. Thanks!