fixes #30 and fixes #36

I ran into a very rare intermittent failure in a test which starts a Qt application and connects to a virtual framebuffer constructed with xvfb. The cause was the race condition between xvfb creating the framebuffer and the Qt application starting.
Under normal circumstances the error is quite rare (happening in 1/2500 runs or so) but the same situation can be emulated with:

Xvfb.SLEEP_TIME_BEFORE_START = 0
while True:
    with Xvfb():
        app = QApplication([])
        app.exit()

which crashes almost immediately with

qt.qpa.xcb: could not connect to display :12345
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, webgl, xcb.


Process finished with exit code 134 (interrupted by signal 6: SIGABRT)

I have replaced the fixed timeout with a loop which waits for the Unix domain socket for the display to exist (which I assume means the display is ready). With this change the above snippet no longer crashes.

An added benefit is that the startup is also much faster (taking only about 5ms on average on my machine).

I know the chances of getting this pull request merged is slim as the project seems abandoned, but this might be useful for other people who run into this problem.