ggml: parallelize dequantization or fp format conversion when using blas

[ReinForce-II]

resolve #4988

• make GGML_TASK_INIT phase can be run in multithread
• move dequantization in mul_mat to GGML_TASK_INIT phase when using BLAS lib and enable multithreading
• update work size to fit fully dequantized weights

[slaren]

This is good as it is, but in the future I think we could remove the init and finalize tasks, and instead have a barrier synchronization function that waits until all the threads working on an op reach the same point. Then the ops could have as many phases as they need, and it might simplify the implementation a bit.

[ggerganov]

I'm not convinced about the sched_yield changes - on macOS I do see performance improvements with CPU + Accelerate, but on my Linux machine with OpenBLAS, whisper.cpp is slower with this change.

I guess we will merge it and look into a more general solution of removing the tasks and synchronizing on barriers

[ReinForce-II]

On Linux with OpenBLAS, when it's running with all available threads by default, a spin not managed in blas lib can compete with it, which can lead to significant downgraded performance. Num threads used by openblas can be set via utility functions in openblas extension, but an equivlant function is not always available in general blas providers. I guess the case can be relieved by environment variable, but it still need something better here.

[JohannesGaessler]

This PR seems to have caused a large performance regression for at least one user: #6417