Prevent accidental increase of the thread count inside a parallel region

[martin-frbg]

fixes #5947

[lindsayad]

I added a test case in #5950 that would hopefully catch a future regression in case you wanted to port something like it over to this PR

[martin-frbg]

Thanks - now you've got me worrying if my patch could be too simple. But as far as I'm aware, trying to run more than one thread when already inside a parallel region is invoking undefined behavior at least with older OpenMP versions (and I think even with the latest one). And the openblas_num_threads_local is unfinished and unrelated to OpenMP.

[lindsayad]

I don't think nested parallel regions (at least with the current standard) is undefined behavior. If it was then the omp_set_max_active_levels API doesn't make much sense https://www.openmp.org/spec-html/5.0/openmpsu125.html

[lindsayad]

This is a pretty important issue for us. We can't update to PETSc main in MOOSE right now because both MUMPS and strumpack call dgemm in threaded regions and so in our threaded testing we just get hangs. I could revert the OpenBLAS version update in PETSc, but I'd prefer not to do that if we think we can get movement on this in not too much time