Huge fixes to restore and capture to properly handle minimize, maximi…

…ze and snapped states

* Realized that both SetWindowPlacement and a precise positioning call are needed to carry "normal" position through as well as return the window to correct position
* Removed the side-effect within the "Has window changed" routine (it was a source of a couple bugs!)
* Factoring the "showCmd" in to calulate placement difference (which is now correctly considered for if the window is changed... before minimized window state wouldn't properly be detected)

* Now ignores cloaked Windows Store apps, reducing the number of wind…

…ows being tracked

* Now handles screen lock/unlock so that capture is blocked until after the screen is unlocked. There was a weird behavior where the layout would be recaptured in the background incorrectly if the lock screen is active and the display arrangement changed. This prevents any incorrect captures from occurring while we wait for restore.
* Reduced stabilization wait to 500ms to improve experience
* Changed where timestamp was added to log output
* Restore routine now simplified to use User32.SetWindowPos() which allows for more control, including Z-Order (that we might want to implement eventuallt). Because this restore seems to handle all cases, we no longer needed to call the User32.SetWindowPlacement() routine

* Added "Wait until windows have stabilized" to both capture and rest…

…ore routines... Should be very efficient

* Some additional constants for if it makes sense to intercept WndProc messages (so far... no benfit)
* Slight tweaks to the algorithsm...

I'll revisit once I've had sleep, but this seems to behave more reliably than before.