Add PACKAGEVERSION token expansion for manifest fields

[Kaleb Luedtke (Trenly)]

📖 Description

This PR adds <PACKAGEVERSION> token expansion for manifest data fields that can include versioned values.

Implemented behavior:

• Expand <PACKAGEVERSION> at manifest parse time (YAML and REST), distinct from runtime installer argument token replacement like <LOGPATH>.
• Supported fields:
  • Installers[*].NestedInstallerFiles[*].RelativeFilePath
  • Installers[*].ProductCode
  • Installers[*].AppsAndFeaturesEntries[*].DisplayName
  • Installers[*].AppsAndFeaturesEntries[*].ProductCode
  • Installers[*].InstallationMetadata.DefaultInstallLocation
  • Installers[*].InstallationMetadata.Files[*].RelativeFilePath
  • DefaultLocale.ReleaseNotesUrl
  • Localization[*].ReleaseNotesUrl
• Added/updated parser tests and test collateral.
• Added release note entry under New Features.
• Added PACKAGEVERSION to the spelling allowlist.

This PR was prepared with assistance from GitHub Copilot.

🔗 References

Resolves#4494

🔍 Validation

• Added and updated unit test coverage in:
  • src/AppInstallerCLITests/YamlManifest.cpp
  • src/AppInstallerCLITests/RestInterface_1_4.cpp
• Added test data:
  • src/AppInstallerCLITests/TestData/Manifest-Good-PackageVersionToken.yaml
  • and wired it in src/AppInstallerCLITests/AppInstallerCLITests.vcxproj

✅ Checklist

• Signed the Contributor License Agreement
• Linked to an issue
• Updated Release Notes (if applicable)
• Updated documentation (if applicable)
• Updated Copilot instructions (if build, architecture, or conventions changed)

📋 Issue Type

• Bug fix
• Feature
• Task

[JohnMcPMS]

I'm not seeing the ROI on taking this change. What is the scenario other than "If I modify the manifest manually I can just change 1 location (instead of find/replace that one thing)."

[Kaleb Luedtke (Trenly)]

I'm not seeing the ROI on taking this change. What is the scenario other than "If I modify the manifest manually I can just change 1 location (instead of find/replace that one thing)."

You're correct that it is primarily ease of authorship. I've also seen scenarios where WingetBot creates updates but things like 'DisplayName` aren’t updated - leading to noise and inconsistiencies if it slips through Stephens automated review and not a manual review. Or similarly, if an exe puts the version as part of their product code manifest updates don’t always catch that - especially if not carefully reviewed

Granted, authorship scenarios are certainly edge cases and the example above could (and probably should) be fixed in other ways. I also see future value in other fields like documentation URLs if those change per version - where tooling (including wingetcreate) doesn’t necessarily remove or update the field automatically.

This was just an idea I had to making it easier for contributors, but understand if this isn’t something the team wants to take in