Strict checking of package installations.

Description of the new feature/enhancement

Add a --strict option to winget install which enforces certain additional checks to ensure applications installed correctly.

Proposed technical implementation details (optional)

Okay, before I start, this won't really make much sense until https://github.com/microsoft/winget-cli/issues/1073 is implemented. Also, I know what I'm going to describe (if anyone even likes it besides me) will most likely need a spec, which I can draft.

#1073 is designed to allow package maintainers to enumerate every ARP entry a installer makes, so that winget has a better time matching. This should mean instead of the guesswork (which is pretty good, but not 100%) winget does now to try to match packages to the ARP table, it can know exactly what is supposed to be there.

I propose that a new option, --strict, be added so that if a package installs and the correct ARP entries are not made (so either less than enumerated in the manifest, or more, or just different/incorrect ones) that winget should say the install failed, perhaps print the differences (--verbose-logs?) and exit with a non-zero code.

This would help a ton with confidence in winget and allow it to start managing packages more than just lighting the firework and running away, which is the current functionality (well, it tells you if the installer said it failed, but the installers often lie). And of course, this functionality could be extended to do other checks based on assertions we can make by Installer Type. From a user perspective, I have more confidence, and from a package maintainer perspective this allows much better automation for package moderation (run the package with --strict. if the metadata didn't match, that's an error that's now super easy to push to a CI step instead of having to write code ourselves to read the ARP table. We shouldn't have to do that, winget already knows what it can and cannot match ;D)

There's a couple drawbacks to this, namely, that MSIX packages don't use the ARP table (but they have an equivalent), and portable applications don't either (but last I heard, the planned implementation of installing portable apps was to create an ARP entry for them. if that's still the case than it could work). It would of course be optional, as packages do all kinds of nasty things sometimes that we just have to go along with. (Chrome changes it's ARP entry on first run, for example. And if a user decides to use --custom, we can no longer guarantee what ARP entries will be made).

Please give me feedback and tell me if this sounds good/useful. I don't think it would be too bad to implement after #1073, but maybe there's some grossness I'm not aware of.

Start by reading issue #1073, which this proposal depends on, then trace the winget install flow and how ARP entries are matched. Define the strict-checking behavior and differences to report, including how installer types, MSIX, portable applications, and --custom affect validation; completion requires an agreed specification and implementation plan.