Expose more settings to Microsoft.WinGet.DSC/WinGetPackage

[rlabrecquefsg]

Description of the new feature / enhancement

I'm migrating over to winget configure from my bespoke winget install scripts, and am running into some missing features in WinGetPackage. This is a request to expose more of winget install and Install-WinGetPackage's settings via Microsoft.WinGet.DSC/WinGetPackage so they can be used with winget configure, and devhome.

Notably missing --custom and --scope for my needs.
I imagine some people would require --location and --architecture, and --override to make use of this feature as well.

For my current needs these only need to be set during install/upgrade.

In the long term it would be nice to have Microsoft.WinGet.DSC/WinGetPackage go down the re-install/upgrade path if say the location, scope, or custom/override settings change. But this should be a seperate ticket once both this ticket and #3281 are complete!

Sorry @denelon, you knew this was coming😄

Proposed technical implementation details

Adding more settings here:
https://github.com/microsoft/winget-cli/blob/e4b9205cff88701b2ad1078dd8ed311ac716b8b6/src/PowerShell/Microsoft.WinGet.DSC/Microsoft.WinGet.DSC.psm1#L545C12-L549C14

Like so: https://github.com/microsoft/winget-cli/blob/master/src/PowerShell/Microsoft.WinGet.Client/Examples/Sample_InstallPackage.ps1#L25

[denelon]

Yep 👍 I knew it was coming.

The goal here would be to essentially provide parity with the CLI in the DSC resource in terms of arguments you can pass to ensure a package is installed.

We'll have to make a laundry list for all the arguments that make sense.

[egerlach]

Just ran into a use case for --installer-type in my configuration.

[OranguTech]

Lack of --scope makes this a non-starter for us.

[denelon]

Another bug we need to address with this is the scenario where an older version of WinGet with an expired certificate for the "msstore" causes the configuration to fail when building the composite source. Those users can remove the "msstore" source, but since the DSC resource is specifying "winget" as the source for the package, it shouldn't worry about trying to connect to the "msstore" source (or any other source for that matter).

When the source is specified in the configuration, it should be treated as a "targeted" source.