Fix choose-visual to not override result if already of preferred class

[tomscii]

This is my stab at getting past the error in #3. I think the problem is that the looping over the rest of the candidates happens even if the first candidate is already one of the desired classes (3 or 4 as per the code comment). In this case, I believe the looping should not happen.

The diff fixes the immediate error in #3, and it allows the program to proceed with putting up a (black) glx-test window, so I think it's a step in the right direction. However, there is still an error, I get this backtrace:

Asynchronous VALUE-ERROR in request 42 (last request was 44)  Code 152.3 [GLX] Value 0.
   [Condition of type XLIB:VALUE-ERROR]

Restarts:
 0: [CONTINUE] Ignore
 1: [RETRY] Retry SLIME REPL evaluation request.
 2: [*ABORT] Return to SLIME's top level.
 3: [ABORT] abort thread (#<THREAD "new-repl-thread" RUNNING {10042AA863}>)

Backtrace:
  0: (XLIB::READ-ERROR-INPUT #<XLIB:DISPLAY :0 (The X.Org Foundation R12011000)> 42 #S(XLIB::REPLY-BUFFER :SIZE 32 :IBUF8 #(0 2 42 0 0 0 ...) :NEXT NIL :DATA-SIZE 32) #<SB-THREAD:THREAD "new-repl-thread" R..
  1: (XLIB::READ-INPUT #<XLIB:DISPLAY :0 (The X.Org Foundation R12011000)> NIL NIL #<FUNCTION (LAMBDA (XLIB::PENDING-COMMAND) :IN XLIB::READ-REPLY) {52D03E7B}> #S(XLIB::PENDING-COMMAND :SEQUENCE 44 :REPLY-..
  2: (XLIB::READ-REPLY #<XLIB:DISPLAY :0 (The X.Org Foundation R12011000)> #S(XLIB::PENDING-COMMAND :SEQUENCE 44 :REPLY-BUFFER NIL :PROCESS #<SB-THREAD:THREAD "new-repl-thread" RUNNING {10042AA863}> :NEXT ..
  3: (XLIB/GLX:MAKE-CURRENT #<XLIB:WINDOW :0 3400002> #<XLIB/GLX::CONTEXT :0 54525957>)
  4: (XLIB-DEMO/GL-TEST:TEST #<FUNCTION XLIB-DEMO/GL-TEST::GEARS> :HOST "" :DISPLAY 0 :WIDTH 200 :HEIGHT 200)
  5: (SB-INT:SIMPLE-EVAL-IN-LEXENV (XLIB-DEMO/GL-TEST:TEST (FUNCTION XLIB-DEMO/GL-TEST::GEARS) :HOST "" :DISPLAY 0) #<NULL-LEXENV>)
  6: (EVAL (XLIB-DEMO/GL-TEST:TEST (FUNCTION XLIB-DEMO/GL-TEST::GEARS) :HOST "" :DISPLAY 0))

So that means make-current runs into an X protocol error, and I suspect that might be because the context established before with create-context might not have worked...