Fix next_fb_id race in the native renderer's CPU copy path

All the details are in the commit messages.

The second commit is not essential, but it would have helped considerably in tracking this issue down by confirming a frozen screen image to be actually a Mutter bug. The original symptom was simply a frozen image on one output while others continued to run just fine. The image freeze was triggered by Mutter switching to drmModeSetCrtc permanently after one random failure with drmModePageFlip. Whether the image freeze was due to the EVDI or DisplayLink drivers not handling drmModeSetCrtc bombardment or Mutter having bugs in the drmModeSetCrtc path, I do not know. This MR fixes the root cause, which was the drmModePageFlip failure due to misuse.

Hitting this problem requires a multi-GPU system, where a secondary GPU is using the CPU copy path. This may be hard to achieve because Mesa is happy to initialize EGL GBM platform using llvmpipe. Then, one needs to get very lucky to lose the race. For example, I could not reproduce the bug by simply having an animating app open partially or completely on a secondary GPU output, it just had to always be moving a window around with a mouse.