glx: Fix visual fbconfig matching with respect to swap method

For the built in visuals, we'd typically select the "best" fbconfig
without considering the swap method. If the client then requests a
specific swap method, say GLX_SWAP_COPY_OML, it may well happen that the
first fbconfig matching requirements would have been paired with the 32-bit
compositing visual, and the client would render a potentially transparent
window.

Fix this so that we try to match fbconfigs with the same swap method to all
built-in visuals. That would guarantee that selecting a specific swap-
method would not influence the chance of getting a compositing visual.

Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit 4486d199)