Add a key for "Requires Elevation" to the manifest schema

[denelon]

Description of the new feature/enhancement

Some packages require elevation to install. The Windows Package Manager could provide settings and or arguments to filter results requiring elevation. Some users may not have the ability to elevate, and this could help eliminate a bad experience for them.

Proposed technical implementation details (optional)

Optional key "RequiresElevation". The default behavior when the key is not present is to treat it as true.

Installers:
  - InstallerType: exe
    InstallerArchitecture: x64
    InstallerSHA256: 12341234123412341234123412341234123412341234
    InstallerURL: https://www.contoso.com/awesomeapp/1.0.0/awesomeapp.x64.exe
    RequireElevation: true

Edit:

We found examples of packages that do not work with elevation. This schema implementation was extended:

winget-cli/schemas/JSON/manifests/v1.1.0/manifest.installer.1.1.0.json

Lines 427 to 435 in 5a97e26

	"ElevationRequirement": {
	"type": [ "string", "null" ],
	"enum": [
	"elevationRequired",
	"elevationProhibited",
	"elevatesSelf"
	],
	"description": "The installer's elevation requirement"
	},

Related To:

• Add messaging to support package specific elevation requirements #1537
• Support installer specific elevation requirements winget-pkgs#29148

[jedieaston]

When is RequiresElevation true and Scope: Machine not true? Since to install applications for the entire system you need to be elevated. We really need a way to filter by scope though, that'd be nice so if I'm on a corporate box I can see what can still be installed.

[denelon]

Yes, that's part of the intent here. We've run across several packages that require elevation even for user install. In some cases it's just a mistake in the installer build while in others, it's required to install a service the "user" package still depends on.

[jedieaston]

I didn't know that some apps did that. That's super lame :(.

[denelon]

#1427