We were space-leaking iris_compiled_shader objects, leaving them around
basically forever - long after the associated iris_uncompiled_shader was
deleted.  Perhaps even more importantly, this left the BO containing the
assembly referenced, meaning those were never reclaimed either.  For
long running applications, this can leak quite a bit of memory.

Now, when freeing iris_uncompiled_shader, we hunt down any associated
iris_compiled_shader objects and pitch those (and their BO) as well.

One issue is that the shader variants can still be bound, because we
haven't done a draw that updates the compiled shaders yet.  This can
cause issues because state changes want to look at the old program to
know what to flag dirty.  It's a bit tricky to get right, so instead
we defer variant deletion until the shaders are properly unbound, by
stashing them on a "dead" list and tidying that each time we try and
delete some shader variants.

This ensures long running programs delete their shaders eventually.

Fixes: ed4ffb97

 ("iris: rework program cache interface")
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <!6075>