Remove "This is taking a long time" progress timeout and TimeoutConfiguration.

Revert "[flutter_tools] reland: fold process resolution logic into the flutter tool (#67957)" (#67968)

This reverts commit bd813879.

Reland of #67669

The flutter tool has a number of crashes on stable where an ArgumentError is thrown due to the process manager not being able to resolve an executable.

So that we can adjust/modify this logic, fold it into flutter and add some additional logging.
caches the resolved executable per target directory, to avoid repeated look ups.
Instead of throwing an argument error, attempts to run the executable as given if an exact path can't be found
Accept files or symlinks for the executable path.
user where/which to resolve path instead of package:process logic.

This reverts commit 10c78c26.

The flutter tool has a number of crashes on stable where an ArgumentError is thrown due to the process manager not being able to resolve an executable. Fold the resolution logic into the tool and use where/which instead of the package:process specific logic.

HACKTOBERFEST

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

Removes the template version from the Windows template; the API and
tooling boundary will now be considered stable, so there will no longer
be frequent breaking changes.

Also updates the link for adding desktop support to a project for all
three platforms to reflect the current location.

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

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

[flutter_tools] support code size tooling on iOS, linux, windows, macOS, and Android on Windows (#63610)

Adds support for size analysis on iOS, macOS, linux, and Windows - using an uncompressed directory based approach. The output format is not currently specified.

Adds support for size analysis on android on windows, switching to package:archive

Updates the console format to display as a tree, allowing longer paths. Increases the number of dart libraries shown (to avoid only ever printing the flutter/dart:ui libraries, which dominate the size)

* Add punctuation for unterminated sentences in doc comments

* Addressing review nit

* 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

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

Builds and bundles an 'app.so' containing AOT data, and downloads and packages the release/profile artifacts for those builds, rather than always using the debug artifacts.

Fixes https://github.com/flutter/flutter/issues/38477
Fixes https://github.com/flutter/flutter/issues/39664

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

- Update the Linux build to support most of the build configuration, though like windows most only make sense for profile/release.
- Ensure VERBOSE_SCRIPT_LOGGING is set when the logger is verbose
- Automatically run pub get like other build commands

Adds initial support for flutter create of apps and plugins. This is derived from the current FDE example app and sample plugin, adding template values where relevant.

Since the APIs/tooling/template aren't stable yet, the app template includes a version marker, which will be updated each time there's a breaking change. The build now checks that the template version matches the version known by that version of the tool, and gives a specific error message when there's a mismatch, which improves over the current breaking change experience of hitting whatever build failure the breaking change causes and having to figure out that the problem is that the runner is out of date. It also adds a warning to the create output about the fact that it won't be stable.

Plugins don't currently have a version marker since in practice this is not a significant problem for plugins yet the way it is for runners; we can add it later if that changes.

Fixes #30704

Updates VisualStudio and VisualStudioValidator to use constructors instead of global injection. Updates VisualStudio test cases to prefer FakeProcessManager
Updates build_windows test to work without injected VisualStudio

Exit, rather than crash, if a Windows plugin is missing its project.

Fixes #51743

Adds utility code for managing list of plugin projects within a solution file, updating them as the plugins change.

This is a prototype of an approach to solution-level portion of Windows plugin tooling; it may not be what the final plugin handling on Windows uses, but it makes things much better in the short term, and gives us a baseline to evaluate other possible solution management systems against.

Part of #32719

Generates a Property Sheet for Windows builds containing link and include path
information for any included plugins. This allows automating part of the process
of integrating plugins into the build that is currently manual.

To support this change, refactored msbuild_utils into a PropertySheet class so that
it can be used to make different property sheets.

This makes ephemeral symlinks to each plugin, for use by build systems.
This is similar to the logic implemented in the Podfile on iOS and
macOS, but managed internally to the Flutter tool.

Exploration for addressing #32719 and #32720
Related to #41146

Moves the checks that projects have been configured for desktop to a lower level, where they will cover more codepaths (e.g., 'run'), and improves them to check for native build projects, rather than just directories, to catch cases where the directory exists (e.g., due to accidental creation of generated files).

Also adds links to the error messages pointing to instructions on adding desktop support to a project.

Fixes #47145