Dependency evaluation with `--scope` parameter

Brief description of your issue

If a user provides --scope for a package installation, winget will try to honor the same scope request for all of the dependencies. This can have problems when a package installs in one scope, while the dependency installs in another scope. Imagine a package supporting multiple scopes (user and machine) while taking the dependency of a runtime (that usually install only in machine scope). The scenario is:

1. User wants to winget install foo.bar --scope user
2. foo.bar takes a dependency on foo.baz
3. foo.baz only supports machine scope
4. Command fails for the user

Steps to reproduce

Taking a real example (as reported by @PckgrBot on Gitter):

1. winget install --id DuongDieuPhap.ImageGlass --scope machine
2. DuongDieuPhap.ImageGlass takes a dependency on Microsoft.DotNet.DesktopRuntime.8 (links point to the manifest)
3. Microsoft.DotNet.DesktopRuntime.8 currently does not define a scope in its manifest so winget treats it as Scope: Unknown (link points to the latest manifest at the time of writing this issue)

Expected behavior

Command should succeed installing DuongDieuPhap.ImageGlass in machine scope, and installing the dependency in its supported scope. If scope is not defined in the dependency's manifest, then winget should fallback to the behavior currently used by winget install/upgrade for the main package when Scope isn't defined in the main package's manifest (i.e., package is installed anyways)

Actual behavior

Command fails.

~ winget install --id DuongDieuPhap.ImageGlass --scope machine
Found ImageGlass [DuongDieuPhap.ImageGlass] Version 9.0.9.1230
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
No suitable installer found for manifest: Microsoft.DotNet.DesktopRuntime.8 8.0.1
Error processing package dependencies, exiting..

Relevant log snippet (full logs attached below):

2024-01-17 19:24:28.474 [CLI ] Installer [Arm64,burn,Unknown,] not applicable: Installer scope does not match required scope: Unknown != Machine
2024-01-17 19:24:28.474 [CLI ] Installer [Arm64,burn,Unknown,] not applicable: Machine is not compatible with Arm64
2024-01-17 19:24:28.474 [CLI ] Installer [X64,burn,Unknown,] not applicable: Installer scope does not match required scope: Unknown != Machine
2024-01-17 19:24:28.474 [CLI ] Installer [X86,burn,Unknown,] not applicable: Installer scope does not match required scope: Unknown != Machine
2024-01-17 19:24:28.474 [CLI ] No suitable installer found for manifest Microsoft.DotNet.DesktopRuntime.8 with version 8.0.1

--scope user does not work either since Scope: unknown is being taken for the DotNet dependency. I imagine it can be fixed if the DotNet dependency supports multiple scopes and we add that in the manifest, but most packages don't support multiple scopes and winget should better deal with these scenarios.

Environment

~ winget --info
Windows Package Manager (Preview) v1.7.3481-preview
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.22621.3007
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.22.3481.0

Winget Directories
-------------------------------------------------------------------------------------------------------------------------------
Logs                               %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir
User Settings                      %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\settings.json
Portable Links Directory (User)    %LOCALAPPDATA%\Microsoft\WinGet\Links
Portable Links Directory (Machine) C:\Program Files\WinGet\Links
Portable Package Root (User)       %LOCALAPPDATA%\Microsoft\WinGet\Packages
Portable Package Root              C:\Program Files\WinGet\Packages
Portable Package Root (x86)        C:\Program Files (x86)\WinGet\Packages
Installer Downloads                %USERPROFILE%\Downloads

Links
---------------------------------------------------------------------------
Privacy Statement   https://aka.ms/winget-privacy
License Agreement   https://aka.ms/winget-license
Third Party Notices https://aka.ms/winget-3rdPartyNotice
Homepage            https://aka.ms/winget
Windows Store Terms https://www.microsoft.com/en-us/storedocs/terms-of-sale

Admin Setting                             State
--------------------------------------------------
LocalManifestFiles                        Enabled
BypassCertificatePinningForMicrosoftStore Disabled
InstallerHashOverride                     Enabled
LocalArchiveMalwareScanOverride           Disabled

Logs (Verbose)

WinGet-2024-01-17-19-24-25.282.log

Start by reproducing the failure with the documented winget install command and review the attached verbose log, especially dependency evaluation and installer scope matching. Trace how --scope is propagated from the main package to dependencies, then verify that a dependency with an undefined or incompatible scope can install in its supported scope and that the reported command succeeds.