More granular control for winget import

Description of the new feature / enhancement

WinGet's import command, while convenient in principle, is, to be blunt, extremely limited. There's no support for custom install arguments and, according to the documentation, it doesn't even respect set preferences. This all effectively makes the command a complete non-starter for anyone who needs more than the default install behaviour (which, if you're going through the trouble of automation, you probably do).

I have to assume there's some technical difficulty in implementing this, since it feels like fairly obvious functionality, but I wasn't able to find any issues bringing it up. In any case, this is my feature request to:

• Make winget import respect and use the preferences set in settings.json (with an option to ignore them)
• Allow special preferences to be specified for a particular import manifest in the file and/or when running the command (with override options)
• Allow custom arguments to be specified on a per-package basis inside the manifest file—particularly, the use of the --custom and --override parameters to specify particular arguments for the package installer

Proposed technical implementation details

Arguments such as --no-preferences, --use-set-preferences, --use-file-preferences, --custom-preferences [custom preferences], etc. could be used with winget import to specify behaviour in regards to preferences declared in WinGet's settings, the manifest file and in the command itself. The user could choose to use default behaviour and disregard any preferences set anywhere (current behaviour), override custom preferences set in the json file and use those set in WinGet's settings, or to provide their own preferences to override the others. By default, manifests providing custom preferences would take precedance over preferences in settings, but a preference in settings (ironically) could be used to change this.

A way to allow "stacking" of preferences, for lack of a better term—perhaps WinGet's settings specify a preferred scope while the manifest specifies a prefered architecture; since there's no conflict between these two settings they could both be used. A flag such such as --(dis)allow-stacking could be used to manage this, and it could also be an option within the manifest.

Preference hiearchy of command options > manifest specifications > WinGet settings would likely be ideal.

Custom preferences in the manifest could be specified in the same format as in WinGet's settings.

Keys such as customArguments or overrideArguments could be used for packages within the manifest as analogues to the --custom and --override options in winget install.

Start by reading the winget import command and the settings.json and manifest preference handling described in the issue. Define the precedence and stacking rules for command, manifest, and settings preferences, including per-package custom and override arguments; done requires an agreed, testable design and corresponding coverage.