mesa: add infrastructure for threaded shader compilation

Drivers can call the new _mesa_enable_glsl_threadpool to enable the thread
pool, and set ctx->Const.DeferCompileShader and/or ctx->Const.DeferLinkProgram
to control what functions are threaded.  To help drivers prepare for deferred
ctx->Driver.LinkShader, ctx->Driver.NotifyLinkShader is added.

There is no restriction on DeferCompileShader, except that applications that
check the compile status immediately after glCompileShader will not benefit
from it.  Worse, they will get punished.  As for DeferLinkProgram, some driver
functions (see struct gl_constants) must be thread-safe.

Signed-off-by: Chia-I Wu <olv@lunarg.com>
i965: add drirc option multithread_glsl_compiler

Setting it to a non-zero value N will cause shader compilation to be deferred
to a thread pool.  When N is greater than 1, it indicates the maximum number
of threads in the pool.  When N is 1, the number of threads is up to the
driver (two for i965).

Signed-off-by: Chia-I Wu <olv@lunarg.com>
i965: enable threaded precompile (WIP)

It looks like brw_select_clip_planes should not be used at shader compile
time.  Imagine the shader program is used by another context.

For each kernel and the aux data, we need to avoid uploading them to the cache
immediately.  Later when we are going to search the cache, upload them then.
But where should we store them?  gl_shader_program->TaskDriverData?  Should we
subclass gl_shader_program?

Same applies for scratch bo realloc.