Fix segfault when gemm is called immediately after set_num_threads

The following julia code (sometimes) segfaults:

~~~
a = rand(100,100)
a*a
dlopen_e("wat")
blas_set_num_threads(9)
a*a
~~~

Waiting between `blas_set_num_threads(9)` and the second `a*a` prevents it from segfault, so it won't segfault if you paste that into the REPL one line at a time.

The exact output varies with the number of threads and changes with each run, but with `MONITOR` and `DEBUG_SMP` set, we always see something like

~~~
Server[11] Calculation started.  Mode = 0x2001 M = 100 N=100 K=100
THREAD[11] : Running2.
Total number of suspended ... 7
Server[11] Thread has just been spawned!
Segmentation fault (core dumped)
~~~

where a thread is spawned after it's already running.

From what I can tell, this is because `blas_thread_init()` gets called, which calls the appropriate `pthread_*` functions to initialize threads. `goto_set_num_threads` also calls the same `pthread_*` initialization code, which means that if there isn't a delay between `goto_set_num_threads`, those threads are awake when the calculation starts.

I don't know openblas well enough to say whether or not this is a julia bug (for violating some contract in the openblas API) or an openblas bug, but it seems like this pull request "fixes" the issue if it's an openblas bug. I put fixes in quotes because I don't know the code well enough to understand the intent here. `make tests` passes after I make this change, (as does `make testall` for julia), but this threading stuff doesn't seem to be tested much, so I could easily be breaking something with this.