mesa/fbo: Don't force both read/draw bindings to zero

... when we're only changing one of the two to zero. I could maybe
understand the old behavior here if we really did need both read/draw to
either be both from winsys or both user, but we don't. You can still
get to that half-and-half state even with the old code, you just need to
set whichever of read/draw to 0 that you want first, and then set the
other to the user fbo.

The first code to introduce a read fb to this path was dbfb375805,
which was trying to make sure we restored both values passed to
glXMakeCurrentRead when going back to fb 0. The commit message suggests
that "the API" doesn't allow split read/draw, but that seems to have
ignored the #ifdef EXT_framebuffer_object code immediately nearby which
did exactly that.

Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18824>

src/mesa/main/fbobject.c

@@ -3279,8 +3279,10 @@ bind_framebuffer(GLenum target, GLuint framebuffer)
       /* Binding the window system framebuffer (which was originally set
        * with MakeCurrent).
        */
-      newDrawFb = ctx->WinSysDrawBuffer;
-      newReadFb = ctx->WinSysReadBuffer;
+      if (bindDrawBuf)
+         newDrawFb = ctx->WinSysDrawBuffer;
+      if (bindReadBuf)
+         newReadFb = ctx->WinSysReadBuffer;
    }
 
    _mesa_bind_framebuffers(ctx,