Windows plugins are designed to share implementations between Win32 and
UWP, but not all plugins will support both. This adds a new
'supportedVariants' key to Windows plugins that allows specifying
'win32' and/or 'uwp' (and potentially others in the future in case that
becomes necessary).

Plugins without any supported variants will be assumed to be Win32 for
backward compatibility.

This will allow compiling Windows projects that use Win32-only Windows
plugins (which is currently all of them) in UWP mode. The plugins will
of course throw missing implementation exceptions at runtime, but tehy
won't prevent being able to build as they currently do.

Fixes https://github.com/flutter/flutter/issues/82815

Depending on the user's build configuration, we may output
multi-architecture or single-architecture binaries. Prefer to install
the multi-architecture binary if built, otherwise fall back to the
single-architecture binary.

This eliminates the use of the Install.ps1 script during Windows app
installation and instead uses uwptool install. Install.ps1 was the
slowest part of app install, and had resource contention issues that
frequently caused it to fail.

Adds UwpTool.install and UwpTool.uninstall methods. Refactors the
PowerShell-based install code to move the powershell-related bits out of
the Device class and into UwpTool so that when we swap out the
PowerShell-based install for the uwptool-based install, it's transparent
to the WindowsUWPDevice class.

Adds implementations for:
* WindowsUWPDevice.isAppInstalled
* WindowsUWPDevice.uninstallApp

Refactors:
* WindowsUWPDevice.installApp

Allow flutter run to work end-to-end with a UWP device.

Uses win32/ffi for the actual launch of the application, injected via
the native API class. This is structured to avoid a g3 dependency.

Install and amuid require powershell scripts for now.

Actually connecting to the observatory requires running a command in an
elevated prompt. Instructions are presented to the user if a terminal is
attached.

This is a rebased version of https://github.com/flutter/flutter/pull/79684
by @jonahwilliams, updated to remove `NativeApi` and replace is with calls
to `uwptool`.

Part of https://github.com/flutter/flutter/issues/82085

* opt out the flutter tool

* oops EOF

* fix import

* Update tool_backend.dart

* Update daemon_client.dart

* fix more

Refactors the desktop devices and workflow to remove unnecessary usage of global variables. This should make it easier to test and continue enhancing the desktop functionality of the tooling

#47161

add different workload & add -products * to vswhere calls to check both Visual Studio IDE and standalone Build Tools. (#64251)

* First pass at CMake files; untested

* First pass of adding CMake generation logic on Windows

* Misc fixes

* Get bundling working, start incoprorating CMake build into tool

* Fix debug, exe name.

* Add resources

* Move cmake.dart

* Rip out all the vcxproj/solution plumbing

* Fix plugin cmake generation

* Build with cmake rather than calling VS directly

* Adjust Windows plugin template to match standard header directory structure

* Pass config selection when building

* Partially fix multi-config handling

* Rev template version

* Share the CMake generation instead of splitting it out

* VS build/run cycle works, with slightly awkward requirement to always build all

* Update manifest

* Plugin template fixes

* Minor adjustments

* Build install as part of build command, instead of separately

* Test cleanup

* Update Linux test for adjusted generated CMake approach

* Plugin test typo fix

* Add missing stub file for project test

* Add a constant for VS generator

Revert "[flutter_tools] separate target platform, host platform, and architecutre (#60119)" (#60147)

This reverts commit 30d97d89.

separate target platform, host platform, and architecture

In google3, the Linux device is always available, and it has confused
people who run the Flutter doctor and see
"• Linux • Linux • linux-x64 • Linux" listed.

Rename the Linux device name to "Linux desktop" and the device ID to
be "linux". Make similar changes to the Windows and macOS
devices for consistency.  This is also  consistent with the web
devices.

The device ID change shouldn't be break -d usage since that does a
case-insensitive prefix match.

On Windows, Process.run assumes the output uses the system codepage by default. This allows specifying it in our wrapper, and sets the encoding for vswhere to UTF-8 since we're passing a flag that forces it to use UTF-8 output.

Fixes #53515

instead of restricting profile/release mode based on whether the tool thinks the device is an emulator, restrict based on the device target architecture and the requested build mode. Notably, this enables release mode on x86_64 Android emulators, but not x86 emulators since we do not support that as an AOT target.

This does not add release mode support for simulators, since this requires us to build and upload artifacts for simulator/x86_64

Current versions of the Windows desktop build files don't require a specific Windows 10 SDK version, but doctor still checks for one since vswhere doesn't allow for flexible queries. This has been a common source of issues for people setting up on Windows for the first time, because the current VS installer by default only includes a newer version of the SDK than what doctor is looking for.

This removes the vswhere SDK check, and instead uses a manual check for SDKs. Since this uses undocumented (although fairly widely used, so relatively unlikely to change) registry information, the check is non-fatal, so that builds can progress even if the SDK isn't found by doctor; in practice, it's very unlikely that someone would install the C++ Windows development workload but remove the selected-by-default SDK from the install.

Now that all requirements are default, the instructions when missing VS have been simplified so that they no longer list individual components, and instead just say to include default items.

Fixes #50487

Throw a toolExit if the windows plugin logic runs on an invalid windows project. Update the supported project check to validate the existence of a Runner.sln file