Pipelines should warn against incorrect inclusion / exclusion of DisplayVersion

Description of the new feature/enhancement

The general advice (as of writing this issue) regarding AppsAndFeaturesEntries: DisplayVersion & version range issues arising from it is:

• If a single manifest requires inclusion of DisplayVersion, then all manifests of that PackageIdentifier should contain DisplayVersion
• DisplayVersion should not be used when it's equal to PackageVersion field

This context is easy to miss when contributing package manifests. The pipelines should warn PR authors when:

• They include DisplayVersion in a manifest update when previous manifests don't have this field
• They exclude DisplayVersion in a manifest update when all previous manifests have this field
• Some manifests of the package have DisplayVersion field while others don't
• DisplayVersion being used in the manifest is equal to the PackageVersion
• DisplayVersion differs from PackageVersion by trailing .0s or in a similar fashion where it would make no difference matching wise to the CLI

The most prominent issues caused by failing to adhere to these guidelines:

• "Infinite upgrade" problem seen in https://github.com/microsoft/winget-pkgs/issues/127319#issuecomment-1935687001, https://github.com/microsoft/winget-pkgs/issues/88726
• Making the index inconsistent, thereby breaking publish pipelines (https://github.com/microsoft/winget-pkgs/pull/181438)

Proposed technical implementation details (optional)

No response

The issue identifies pipeline validation of package manifests as the entry point; begin by finding the existing validation that compares manifest versions and fields. Done means the pipeline warns for each listed DisplayVersion inconsistency, including trailing .0 differences, across the affected manifest sets.