[vcpkg] Add semantic handling for nuget_version with two-segment versions

[FrankXie05]

Description:

This PR introduces a minor enhancement to handle the nuget_version field more effectively when exporting NuGet packages. Specifically:

• If the provided nuget_version has only one period (.), such as 1.2, it will be automatically transformed into 1.2.0 to align with NuGet's semantic versioning.
• Versions already adhering to full semantic versioning (e.g., 1.2.1) or other formats remain unchanged.

Reason for Change:

• NuGet requires fully qualified semantic versions. While NuGet itself will raise an error for invalid version formats (e.g., 1.2.), this change preemptively adjusts common cases like 1.2 to avoid such errors and improve the user experience.

Changes Made:

• Modified the nuget_version handling logic to append .0 if only one period is found in the version string.

Testing:

• Manually tested scenarios with:
  • 1.2 → transformed to 1.2.0
  • 1.2.1 → remains unchanged
• Invalid formats like 1.2. → left as-is, allowing NuGet to handle errors as expected.
  

Impact:
This change ensures better alignment with NuGet's versioning requirements and reduces common user errors when specifying a version.

Fix vcpkg issue: microsoft/vcpkg#18543
@GreyCat Could you please test this PR? :)

cc @BillyONeal

[BillyONeal]

Did NuGet emit a warning or something that we are suppressing that we should be reporting instead rather than trying to guess what the resulting file name will be?

Do we know we are resolving the situation in the same way NuGet does?

[FrankXie05]

Warnings and behavior with NuGet: This change is not intended to suppress any warnings or errors emitted by NuGet. NuGet will still throw errors for invalid formats (e.g. 1.2.), and I will not cover or speculate on what NuGet will ultimately do in such cases. Instead, this PR handles a specific common scenario (1.2), which is a valid format, but inconsistent with NuGet's fully qualified semantic versioning.

Consistency with NuGet: The logic implemented here mimics NuGet's expected behavior by appending .0 to versions with only a period (e.g. 1.2 → 1.2.0). To confirm consistency, I have manually tested the results against NuGet, and the output filenames and behavior are consistent with NuGet's expectations. However, if there are any other edge cases we should investigate, I'd be happy to explore further.

[BillyONeal]

Instead, this PR handles a specific common scenario (1.2), which is a valid format, but inconsistent with NuGet's fully qualified semantic versioning.

So the existing behavior is "if the user enters 1.2 that fails when we try to invoke NuGet?"

The logic implemented here mimics NuGet's expected behavior by appending .0 to versions with only a period (e.g. 1.2 → 1.2.0).

NuGet's command line appends the .0?

[FrankXie05]

No, vcpkg will not fail if you pass nuget_version to 1.2.
vcpkg's current behavior is that the version number you pass in does not match the version number you actually pass in.
The reason for this is that nuget's semver semantics will automatically add .0 suffix to versions that match the semantics of X.Y.