AppsAndFeaturesEntries added by default map fields unneccesarily

[Trenly]

Brief description of your issue

When parsing an MSI, AppsAndFeaturesEntries are added automatically. However, fields that should be left out under certain conditions are included contrary to the advice the community has received in the past.

DisplayVersion is included even when it is the same as PackageVersion -> The community has been told this is bad as it creates a version range mapping unnecessarily
DisplayName is included even when it is the same as PackageName
Publisher is included even when it matches the Publisher in the defaultLocale manifest

Steps to reproduce

wingetcreate new with any MSI package

Expected behavior

DisplayVersion would only be included if it does not match PackageVersion

Actual behavior

Unnecessary fields are included

Environment

PS E:\winget-pkgs> wingetcreate info
Windows Package Manager Manifest Creator v1.9.3.0
Copyright (c) Microsoft Corporation. All rights reserved.

Operating System: Microsoft Windows NT 10.0.26100.0
System Architecture: X64

Winget-Create Directories  Path
------------------------------------------------------------------------------------------------------------------------------------------
Logs                       %LOCALAPPDATA%\Packages\Microsoft.WindowsPackageManagerManifestCreator_8wekyb3d8bbwe\LocalState\DiagOutputDir
User settings              %LOCALAPPDATA%\Packages\Microsoft.WindowsPackageManagerManifestCreator_8wekyb3d8bbwe\LocalState\settings.json
Installer cache            %TEMP%\wingetcreate

[Trenly]

@vedantmgoyal9 - I belive you introduced this in #550

@mdanish-kh - Does #575 fully address this, or will DisplayVersion still be added when updating a manifest? I believe that the flow should only update properties of AppsAndFeaturesEntries that are currently present, and not add any that are not present

[mdanish-kh]

I believe that the flow should only update properties of AppsAndFeaturesEntries that are currently present, and not add any that are not present

@Trenly - That's exactly how the current update flow plays out. The change in #550 probably unintentionally affected the NewCommand flow, which should be fixed in #575

[Trenly]

I'll presume #575 fixed this