Use proper version semantics instead of int versions when detecting updates

[craxal]

Currently, we use int versions to detect whether an update is available for the current version of Storage Explorer. Because int versions always increment, this becomes problematic when patch updates are released after minor updates.

For example, say the following versions are released in sequence:

1. 1.9.0 (20)
2. 1.10.0 (21)
3. 1.9.1 (22)

With the current version comparison logic, 1.9.1 would mistakenly be considered an update for 1.10.0.

This problem can be solved by using proper version semantics (i.e. 1.9.1 < 1.10.0, so it would not be considered an update for 1.10.0).

[MRayermannMSFT]

The example scenario does not require the given solution. Despite the name intVersion, using decimals is supported. For the example, 1.9.1 would be given a number like 20.1. I am not seeing the need to making changes to the existing system at this time.

[craxal]

Yes, decimals can work around the problem, and that's exactly what we did. But that's why, after discussion, we opened this issue in the first place. We recognized the weakness of int versions. Decimals were a temporary workaround for this problem. Upgrading to proper semantic version comparisons is the next step.

[MRayermannMSFT]

I don't recall any discussion about this. Additionally, switching to semver will be a breaking change with updates. This does not seem like a strong enough "weakness" to warrant the downsides that come with that. In 7 years of using intVersion we've had one occassion of needing to use a decimal. If this was a recurring issue, I could agree with the urgency to switch to semver.