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

Updates the Linux templates to use CMake+ninja, rather than Make, and updates the tooling to generate CMake support files rather than Make support files, and to drive the build using cmake and ninja.

Also updates doctor to check for cmake and ninja in place of make.

Note: While we could use CMake+Make rather than CMake+ninja, in testing ninja handled the tool_backend.sh call much better, calling it only once rather than once per dependent target. While it does add another dependency that people are less likely to already have, it's widely available in package managers, as well as being available as a direct download. Longer term, we could potentially switch from ninja to Make if it's an issue.

Fixes #52751

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

When generating the plugin registrant for Linux, also generate a
makefile that can be included in the app-level Makefile to manage all of
the plugin targets and flags, exporting them in a few known variables
for use in the outer makefile.

Part of #32720

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

This reverts commit 5eb394e0.

* Reland: [flutter_tools] File system utilities

* Remove unused imports

This reverts commit 03496606.

* Update project.pbxproj files to say Flutter rather than Chromium

Also, the templates now have an empty organization so that we don't cause people to give their apps a Flutter copyright.

* Update the copyright notice checker to require a standard notice on all files

* Update copyrights on Dart files. (This was a mechanical commit.)

* Fix weird license headers on Dart files that deviate from our conventions; relicense Shrine.

Some were already marked "The Flutter Authors", not clear why. Their
dates have been normalized. Some were missing the blank line after the
license. Some were randomly different in trivial ways for no apparent
reason (e.g. missing the trailing period).

* Clean up the copyrights in non-Dart files. (Manual edits.)

Also, make sure templates don't have copyrights.

* Fix some more ORGANIZATIONNAMEs

There has been some confusion about whether or not
.flutter-plugins-dependencies should be tracked in version control or
not. Added a comment to both it and .flutter-plugins explaining that
it's generated and shouldn't be.

.flutter-plugins-dependencies is parsed through JSON, and the JSON spec
doesn't support comments. So unfortunately the note is living in an
arbitrary "_info" key instead of an obvious top level comment.

* implicit-casts:false on flutter_tools

* use castStringKeyedMap

* address review comments

* address review comments

* fix issues after rebase

Add `.flutter-plugins-dependencies` to the project, which contains the app's plugin dependency graph (#45379)

* implicit-casts:false on flutter_tools/lib

* address review comments

* use castStringKeyedMap

* introduce {bool,string,strings}Arg

* fix ci