meta: Don't use integer handles for shaders or programs.

meta: Don't use integer handles for shaders or programs.

Previously, we gave our internal clear/blit shaders actual GL handles
and stored them in the shader/program hash table.  We used ordinary
GL API entrypoints to work with them.

We thought this shouldn't be a problem because GL doesn't allow
applications to invent their own names for shaders or programs.
GL allocates all names via glCreateShader and glCreateProgram.

However, having them in the hash table is a bit risky: if a broken
application guesses the name of our shaders or programs, it could
alter them, potentially screwing up future meta operations.

Also, test cases can observe the programs in the hash table.  Running
a single dEQP process that executes the following test list:

dEQP-GLES3.functional.negative_api.buffer.clear
dEQP-GLES3.functional.negative_api.shader.compile_shader
dEQP-GLES3.functional.negative_api.shader.delete_shader

would result in the last two tests breaking.  The compile_shader test
calls glCompileShader(9) straight away, and since it hasn't even created
any shaders or programs, it expects to get a GL_INVALID_VALUE error
because there's no such name.  However, because the clear test ran
first, it created Meta programs, so an object named "9" did exist.

This patch reworks Meta to work with gl_shader and gl_shader_program
pointers directly.  These internal programs have bogus names, and are
never stored in the hash tables, so they're invisible to applications.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94485
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>