Fix window position for multi-screen setups, and add config file versioning

With a multi-screen setup, pixel coordinates are expressed relative to the top left of the system's default screen. This means that, with two screens where the default is on the right, the x-coordinates of the pixels on the left screen are expressed as negative integers. So we cannot assume that valid window positions are only zero or positive.

Negative positions were being used to represent 'no specific position' as a default. That means that when the windows are created for the first time, we let the operating system decide where to place them. As we should not be using negative positions for this purpose, since they are in fact a valid range of pixel positions, use nullable types instead. The default 'no specific position' is now expressed when the positions are null.

Unfortunately, we still need to handle the special case where the window position is stored as -32000 in the config file. This was the previous default position for non-main windows (timer window,opponent window, and player window). So if the user has already used the previous version of this application, but has not yet opened a non-main window, they will have -32000 stored in the config file.

We obviously do not want to just blindly use this otherwise valid value as it will position the windows far off the screen for most users. To solve this issue, I have added config file versioning in order to handle all legacy config file logic in one place.

We now save a CreatedByVersion string in the config file. With this in place, we can determine which version of the application wrote the config file when we load it. If the version doesn't exist in the config file, we assume it was created prior to the new version. This allows us to change the semantics of config variables in the future and have a mechanism for handling it without breaking users' legacy config files. We are able to interpret and update users' legacy config files to the current semantics.

With this in place, we can handle -32000 values by just interpreting them as the default 'no specific position' when we see that it comes from a legacy config file. If it doesn't come from a legacy config file, we would just interpret it as a valid coordinate (though you'd have to have a pretty high resolution to get it!).

I have also updated the default player and opponent window height logic to be more sensible and consistent with the way default timer window dimensions are implemented. Player and opponent window heights were previously set to zero as a default, and then a bit of logic was used when creating the windows: if height == 0, then set height to 400. This was a little pointless and inconsistent with the default timer window dimensions. Unfortunately we cannot make this consistent without breaking legacy config files, where the height may still be stored as zero. So we handle the changed semantics here.