[Mesa-dev] Rework use of gl program structures

[Timothy Arceri]

I started out with a goal of freeing _LinkedShaders after linking as this
would have allowed a bunch of code simplification and also reduced the
possibility of subtle bugs in i965 where a program that is currently
active is relinked but fails and then we recompile a variant of the still
active program but we would have lost things such as per stage atomic
bindings which would be deleted during the failed relink.

In the end this series grew larger than expected so for now this series
aims to switch the pipeline objects CurrentProgram array from using
gl_shader_program to gl_program. Previously the CurrentProgram array
could have contained multiple pointers to the same struct which was
confusing and we would often need to fish out the information we were
really after from the gl_program anyway. Using gl_program makes much
more sense and allows us to optimise some critical paths such as SSO
and sampler validation which are called at draw time.

In patch 68 when we finally change the pointers used in CurrentProgram
you can see some of the confusion caused by the old way of doing things
where use_shader_program() calls 
_mesa_shader_program_init_subroutine_defaults() on each stage in
gl_shader_program but we also call use_shader_program() itself for
each stage in gl_shader_program so unless we are dealing with single
stage SSO programs we will initialise subroutine defaults many
times over. 

Patch 11 is noteworthy as it creates a gl_program at the start of
linking which allows us to just set values directly rather than
copying them from gl_linked_shader at a later time. Patch 55 is
a good example of one of the many clean-ups this allows.

On top of all this these changes should help make shader cache cleaner
(once I get around to rebasing and fixing it) and hopefully resolve
some of the problems I was having figuring out how to get it working
for SSO.

I've tried to make the order of the patchs make sense for reviewing
but since almost everything is working towards the last 3 patches
reviewers may need to jump to the last few patches at times.

Finally the last 3 patches will need to be squashed to stop
compilation errors I've just split them up to help make reviewing
easier. I would have liked to have made patch 69 separate but the
patches have some circular dependencies that made it difficult.

I'm really happy with how this series turned out and the improvements
I was able to make along the way. Please review.