Warn if manifest is using a newer schema version

[jedieaston]

Description of the new feature / enhancement

As more features and functionality are added to winget, new versions of the manifest schema are created to support these features. Often times new Installer Types or other functionality don't constitute breaking changes, but are not supported in older versions of winget.

winget should be able to explain this to the user in a helpful way, either as a warning (for minor schema updates) or an error (for major schema updates, like 1.x -> 2.x). There's a case to be made for it only being an error, but sometimes new schemas only add metadata fields that aren't relevant to whether winget can install a package, so I think it should just be a warning and the user can decide to abort if they want.

C:\Users\epillay> winget install Mozilla.Firefox
Found Mozilla Firefox [Mozilla.Firefox] Version 98.0
Warning: This manifest is using a newer version of the Windows Package Manager schema than this client supports. 
We'll attempt to install the package anyway, but it is recommended that you check the Microsoft Store for updates.
<...>

or

C:\Users\epillay> winget install Mozilla.Firefox
Found Mozilla Firefox [Mozilla.Firefox] Version 98.0
Error: This manifest is using a newer version of the Windows Package Manager schema than this client supports. 
This client is unable to use the new manifest for installation. Update App Installer in the Microsoft Store to continue.
C:\Users\epillay> # Darn!

Proposed technical implementation details

I don't know if the pre-indexed source currently sends along ManifestVersion, but it would need to for this to work. I'm almost certain the REST source doesn't, but I haven't looked at it in a hot second.

If anyone cares, prior art exists for this in NPM (and I'm sure other package managers). I've seen this quite a few times when Node isn't up-to-date in CI environments:

npm WARN read-shrinkwrap This version of npm is compatible with lockfileVersion@1, 
but package-lock.json was generated for lockfileVersion@2. I'll try to do my best with it!

[jantari]

Related, winget-cli should also communicate to a source which manifest / API versions it supports.

There has been an "APIVersion" query parameter for a long time: https://github.com/microsoft/winget-cli-restsource/blob/f134943b3e28be3422031944db150892fda1a90d/documentation/WinGet-1.4.0.yaml#L591 but it's never set by the client.

This means a source doesn't know which packages it can safely return to a querying client without causing errors or warnings due to incompatibilities (e.g. it would be of no use to return portable-package manifests to an old incompatible client).

See also: https://github.com/microsoft/winget-cli-restsource/issues/194