Delete GLX_OML_swap_method, drop non-srgb-capable visuals

Alternative approach to !25627

glx: Delete support for GLX_OML_swap_method.

This was an ill-advised extension.  While we advertised SWAP_COPY support,
we might implement it with a back-copy from the front buffer.  And we
never advertised EXCHANGE because we couldn't guarantee it.  So, if you
actually used this extension to try to reduce app redraws of the back
buffer, you might actually increase the bandwidth you used.  Whoops.

Instead, GLX_EXT_buffer_age and the similar EGL extension give you
feedback on what's left in your back buffer, letting you do minimum
redraws.

This reduces our GLX visual+fbconfig count from 1410 to 940 on an llvmpipe
X server.  Reducing visual counts will improve test runtime for
visual-iterating tests like piglit's glx-visuals-*.

and

dri: Drop exposing non-srgb formats when srgb is supported.

Previously, our visuals list would have unorm 8888 formats followed by
srgb 8888 formats when the driver supported both, so if you didn't
explicitly ask for srgb support when choosing your visual, then it
wouldn't support it.

For desktop GL, this is probably a no-op since SRGB encoding is disabled
by default, so you'd only see an effect if the app manually enabled SRGB
without having intentionally selected an SRGB visual.

For GLES on EGL, EGL uses a linear colorspace by default, so you won't get
sRGB encoding unless you chose to set the surface to srgb.

For GLES on GLX, SRGB encoding is enabled by default, and now you'd end up
with sRGB encoding even if you didn't go asking for it.  Given that NVIDIA
only exposes srgb-capable GLX visuals as well, we're probably fine syncing
up with them on this.

This reduces our GLX visual+fbconfig count from 940 to 680 on an llvmpipe X server

I am so hesitant about this second change.