When upgrades cannot respect installed package, throw a warning and require --force

Description of Feature

During some very early discussions (2019), we were working on the characteristics that would uniquely define an installer within a manifest for a particular version of a package:

• Installer Type (MSIX, MSI, EXE)
• Architecture (x86, x64, ARM, ARM64)
• Target Platform (Desktop, Server)
• Locale (BCP-47 format)
• Scope (User vs. System)

I would add that there should likely be a priority order here - where if a user has a specific architecture installed, that should be respected even if the underlying installer type changed. Ideally all of these uniquely defined installers would be present in the manifest, but with many different permutations of install parameters, it's likely that one (or more) could be missing from the definitions. The client should be able to reasonably detect when an available version doesn't have an architecture matching the installed architecture, same with scope and, where possible, locale.

Originally posted by @Trenly in https://github.com/microsoft/winget-cli/issues/3940#issuecomment-1836405409

Implementation Details

Ideally, when an upgrade would fundamentally change the existing install in architecture, locale, or scope, the upgrade should be aborted and the user required to force the upgrade. Inspiration can be taken from the implementation for different installer types.

This would only apply to winget upgrade <query> when no --architecture, --scope, --installer-type selectors are provided, as there are other feature requests to make those install the latest applicable version.

Start by tracing the winget upgrade <query> command path and how it compares installed and available installer architecture, locale, and scope. Check the existing handling for installer-type changes, then define tests for aborting with a warning when selectors are absent and permitting the change only with --force.