Update NSSM versioning script to change version calculation

NSSM versions should always be positively incremented to prevent the MSI installer from removing nssm.exe on upgrade.

More details about the reasoning are in PE-22261, but to summarize:

• MSI installs follow some rules regarding versions, and it seems we've tripped on one of the rules accidentally - https://msdn.microsoft.com/en-us/library/windows/desktop/aa368599(v=vs.85).aspx
• A blog post goes into more detail about the problem we're running to. In addition to determining versions differently we could

Schedule the RemoveExistingProducts action before the costing actions in version 2 of the MSI (as described on Stack Overflow).

• The NSSM binary is versioned with https://github.com/puppetlabs/nssm/blob/master/version.cmd. The 1.10.7 release "rolled back" the version to 2.24.0.0 because we tagged our copy of NSSM with a new tag 2.24.1 to keep track of something "versioned" within the puppet-agent repo. Unfortunately the version.cmd script doesn't take into account the third (patch / z) number. The previous build that we used was based on Major.Minor.CommitsPastTag.JenkinsBuild - in other words, exactly at the 2.24 tag BUT the 74th build in the original authors Jenkins system, hence 2.24.0.74. Using a Jenkins build number is a fragile way of calculating version, and I think that we will have to change the versioning system to Major.Minor.Patch.CommitsPastTag.

To do this requires modifying the version.cmd script in NSSM to produce a version from Major.Minor.CommitsPastTag.JenkinsBuildNumber to Major.Minor.Patch.CommitsPastTag