[New Feature]: Package Audit

Description of the new feature/enhancement

Use a server to audit every package, however a background program will automatically record the following:

1. When installing, what files (full file paths) are added to the drive including their hashes and filesize, what files are being edited, and which files are being deleted
2. When installing, what registry keys (including their values) are added to the drive
3. When installing, what URLs are being accessed and possibly what data (including the packets themselves) is being uploaded
4. When installing, record the installer log.
   After installing, or for portable packages, each shortcut added by the package, or portable packages added, will open one at a time, close, and the next one will open. The following should be recorded
5. When opened for the first time, take a screenshot if the app is GUI based, otherwise get the output via opening it from the command line. Also get the output of the -h, --help, /h, and /help flag of every program.
6. When opened, record what files are being added to the drive including their hashes and filesize.
7. When opened, list URLs that have been accessed and probably what data is being uploaded
   All the data will go onto a seperate Microsoft server or a seperate GitHub repo.

The purpose of this is for various tasks later on, but include the following:

1. Adding the specific filetypes the package can open to the manifest, so users who are having trouble opening a file can use winget to search which programs open their file, and possibly add the output of the help flags and no flag inside of the manifest to give the user an idea of what flags the program contains so they can get more info than a tiny description
2. Adding the post-installation filesize of the package.
3. The specific AppData and other user data folders that the apps create on startup could be helpful in adding commands such as how large user data in the app is.
4. Helping power-users and admins a lot in manual, complete app uninstallation as well as projects that do so.
5. Detecting installers that use insecure HTTP, or apps who steal user data without consent
6. Helping a future addition of WinGet community packages into the Microsoft Store a lot in terms of metadata.
7. Potentially helping other open source projects made by the community, including win32-app-isolation
8. To be similar to this: https://www.shouldiremoveit.com/Google-Chrome-5006-program.aspx
9. Potentially creating a force uninstall command in the future, in case a program malfunctions, as well as commands to delete the application excluding the user data, or clear user data like on Android.
10. If win32-app-isolation becomes default (in a future version of Windows, or future per-organization policy), this may help with moving program files and data to sandboxes, and it may help the transfer of user data between two Windows computers.

Proposed technical implementation details (optional)

No response

No files, tests, or entry points are identified. Start by reviewing the package installation and portable-package workflows, then determine the scope for collecting filesystem, registry, network, installer-log, help-output, and launch data. Done would require an agreed design, storage destination, privacy boundaries, and implementation plan for the proposed audit system.