[New Feature]: Warn if number of installer nodes is inconsistent between versions

[Trenly]

Description of the new feature/enhancement

This suggestion comes from the discussion in #92590.

When new manifests are submitted, the validation pipelines should be able to identify if the number of installer nodes differs from the previous version's manifest. This can be the basis for a set of validation parameters which could trigger warnings.

Proposed technical implementation details (optional)

First iteration - Apply a label such as Possible-Missing-Metadata if number of installer nodes is less than previous version.

Second iteration - Compare not only the number of installers, but also the node type. For example - v1.0 contains x86-user-exe and x86-machine-exe, v2.0 (in PR) contains x86-unspecified-exe and x64-unspecified-exe; even though number of nodes are the same, not all the node types from the first manifest are present in the second manifest. Apply the label.

Third Iteration - Compare not only number and type, but also metadata fields. Example - v1.0 contains AppsAndFeaturesEntries (or ReleaseDate, Commands, FileExtensions, etc.) but v2.0 (in PR) does not. Apply the label

[Trenly]

@stephengillie - Area-Validation-Pipeline please

[mdanish-kh]

One reason why newer manifests don't retain metadata from the previous ones is simply because their fork is out of sync with the upstream branch. Many users use YamlCreate to update manifests and it uses the local latest manifest as the base manifest for an update. If the users don't update their fork and git pull into their local repo, they won't have the latest changes that were applied to the older manifest. (I recently encountered this where I added the scope-related switches for a manifest to resolve an issue and a newer one was added by a user using YamlCreate that did not contain the switches, causing the original issue again where users were not able to upgrade the package due to scope mismatch. I noticed the user's fork was some 3000 commits behind the upstream)

We can mitigate the issue if we update YamlCreate to fetch the latest manifest from the upstream repo, or have an option for users to sync their branch first before updating a manifest. The issue doesn't appear with winget-create as it always fetches the latest manifest from the repo.