This looks okay, although I'm not sure we should actually allow unsetting the driver. Maybe calling `wl_display_connect` earlier would be enough?
This change here should work as intended within explorer, because it loads the drivers individually, triggering their unixlib init first, which would call `__wine_set_user_driver( driver_funcs )` and eventually in wayland case `__wine_set_user_driver( NULL )`.
In other processes however, user driver loading is triggered from various win32u calls, which waits for explorer to select a driver (written in the registry), then loads them. If this fails at this point (because wayland is unreachable from the context of this process, regardless of what explorer.exe decided), I think `__wine_set_user_driver( &null_user_driver, WINE_GDI_DRIVER_VERSION )` is called regardless of what loading the user driver did.
This means that in each case we get a different end result (in the first case we get back to lazydrv, in the second we get nulldrv funcs). If we decide to do this maybe we should at least make it consitent?