What happens is that we get the WM_WINE_SETACTIVEWINDOW message sent by the
other thread after we already changed the foreground window back to our own
window.

This is needed so that ImagingFactory can have a threading model of Both.

Perhaps interesting to note is that this returns an IDirectDrawSurface instead
of an IDirectDrawSurface4.

This is a pretty naive implementation, should that become a performance
problem it's easy enough to speed up with a search tree of some kind.

This should be handled by the context's draw buffer management.