Add a new package field named 'Unreliable/Winget-Unstable' for problematic packages

[Anutrix]

Description of the new feature / enhancement

There are a lot of winget-pkgs that are broken when installed through winget.

• Things like Gyan.FFmpeg can be installed but not uninstalled ([Package Issue]: Gyan.FFmpeg winget-pkgs#181353).
• Discord always has version issue but can't be removed to maintain backward compatibility/not break existing workflows ([Package Issue]: Discord.Discord doesn't update DisplayVersion -> remove Discord.Discord winget-pkgs#172175 (comment)). There are so many duplicates of this issue with no resolution.
• And so on: https://github.com/microsoft/winget-pkgs/issues?q=is%3Aissue%20state%3Aopen%20label%3AIssue-Bug

So instead of removing a package, can we add field Unreliable or Winget-Unstable(or anything more-suited) to a package which we know has issues when installed through winget.
It would just the add a Note at the end of installation or even with winget show saying the installation may have issues.
The whole point is to keep User informed of what's happening.
Note that we can't use the word 'Deprecated' for field name as that is something that package-dev would state.

Proposed technical implementation details

• We add optional field named Unreliable or Winget-Unstable to packages that which we know or have confirmed have issues when installed through winget or in general -> winget-pkg change.
• It would just the add a Note at the end of installation or even with winget show saying the installation may have issues -> winget-cli change.
• Above could be extended to add individual notes or details. Or marked as 'version-mismatch issue', 'uninstall issue', '', etc. -> winget-pkg and winget-cli change.

[stephengillie]

Instead of just being a Boolean value, this could probably be a string, listing the way in which the outcome is unstable. There could be a known list of valid values to choose from, each tied to an Issue.

[denelon]

Installation Notes are available today to help inform users if there are important things to know after installing a package.

There are other fields that can help here as well related to upgrade behavior like "deny" and requiring explicit targeting.

I know it's not the exact ask, but I wanted to call out some of the things that could help "today".

Naming things is hard, so we'll have to come up with a few options to figure out the best way to handle the cases where installers don't do exactly what one would expect.