When blur is requested, open the window before blurring

[kolayne]

Description

When locking screen, first open the window with a color (specified with --color) as background, then, if blurring is requested, do that and redraw window.

My use case is to lock screen when the laptop lid is closed (I use xss-lock for that) but sometimes i3lock-color doesn't manage to do the blurring in time, as a consequence, when the lid is opened, one has about a second or two to see the screen before the screen is locked. The solution is to first open the window earlier, and update it after processing the blur.

Relates to #239. Not sure if the PR resolves it, but it can certainly act as an intermediate solution before a fancier locking mechanism, as requested by the issue author, is implemented. By the way, I think, the requested behavior is achieved with running i3lock -B <sigma> --color '#00000000': it will first open the window with fully transparent background, then blur the screenshot and update the window whenever it has finished the processing.

Release notes

Notes: open the lock window earlier when locking with blurring

Behavior worth noticing

1. If one starts typing their password when the window is open but the blurring is still in progress, the decoration won't appear immediately but after the blurring process is over, all the keyboard events are delivered and processed properly, unless the enter key was pressed. But if it was, the lock screen at first seems to behave the same way (that is, all the decorations appear and it then shows the "verifying..." caption), but it remains stuck in the verifying state until I try to retype my password and verify again. Even with the --no-verify option, pressing enter on the early window stage will bring it to the verifying state.
   I would appreciate a hint on why this could be happening. If you know how to fix this, feel free to submit a patch, otherwise I will try to dig deeper into this later when I have time.
   No 'unless' anymore, everything is fine now :)
2. I am not sure if i3lock-color is supposed to support the --image and --blur options together and, if yes, what behavior is expected, but it would probably make sense to display the background image while the blurring is in progress, not a solid color. Should it?
3. PR also fixes the behavior in case the user has completely typed its password and pressed Enter before the initialization has completed. This behavior was present before the patch, but with the patch it has gotten easier to encounter accidentally, so I fixed it. I had to use an additional variable, but I'm not closely familiar with the ev and xcb libraries, so I might have missed a more elegant solution.

[kolayne]

Hello!
@Raymo111, not sure if GitHub notifies the maintainer when a draft is converted to a PR, so just wanted to let you know that this is ready for review.