Adds very preliminary support for Windows and Linux plugins:
- Adds those platforms to the new plugin schema, initially supporting just a plugin class.
- Adds C++ plugin registrant generation for any Windows or Linux plugins found.

This doesn't have yet have any build tooling for either platform, so anyone using the generated registrant still needs to do manual build configuration. This reduces the manual work, however, and creates a starting point for future tooling work.

As with all Windows and Linux work at this time, this is not final, and subject to change without warning in the future (e.g., Windows could potentially switch to a C# interface, or
'linux' may change to 'gtk' or 'linux_gtk' in pubspec.yaml).

When the plugin list changes, iOS pods are invalidated, but that was
never wired up for macOS.

Should fix #39327

Make FlutterPluginRegistrant a static framework so add-to-app can use plugins with static frameworks (#40401)

swift-format will alphabetize import statements, so Flutter* should be
before Foundation. Also, separating the "Generated file" comment
prevents the formatter from thinking that the comment is associated with
the following import, rather than the file, if it does re-order.

* WIP on web plugin registry

* WIP on registering plugins

* WIP on web plugin registration

* Only generate `package:flutter_web_plugins` imports if plugins are
defined

* Add parsing test

* Add documentation

* Fix analyzer warnings

* add license headers

* Add tests for package:flutter_web_plugins

* Run `flutter update-packages --force-upgrade`

* Fix analyzer errors

* Fix analyzer error in test

* Update copyright and remove flutter SDK constraints

* Enable tests since engine has rolled

* add flutter_web_plugins tests to bots

* Create an empty .packages file for WebFs test

This reverts commit bd52a78c.

Instead of sharing the iOS codepath that uses an ObjC generated plugin
registrant and expecting plugins to have an ObjC interface layer, switch
to generating a Swift registrant and expecting plugins to have a Swift
interface.

This means plugins on macOS that use Swift won't need an ObjC wrapper,
and plugins that use ObjC will need a Swift wrapper (inverting the
structure relative to iOS).

Enables the CocoaPods-based plugin workflow for macOS. This allows a
macOS project to automatically fetch and add native plugin
implementations via CocoaPods for anything in pubspec.yaml, as is done
on iOS.

Splits Xcode validation out of the iOS validator and into a stand-alone
validator, and groups the CocoaPods validator with that top-level
validator instead of the iOS validator. iOS now validates only the
iOS-specific tools (e.g., ideviceinstaller).

Reorganizes many of the associated clases so that those that are used by
both macOS and iOS live in macos/ rather than ios/. Moves some
validators to their own files as part of the restructuring.

This is the macOS portion of #31368

Adds a new macosPrefix, which serves the same purpose as iosPrefix but
for macOS plugins.

It is not yet used by the tooling, but this allows for plugins to start
to be written using it in preparation for tooling support for plugins.

Part of #32718

We decided that redefining the default for templates was premature. We're going to go back to having "module" in experimental land again, and we'll try again when we have the feature set fully baked.

This keeps the writing of the .metadata files, and writing the template type to them, because that was a good improvement, and there are still a bunch of added tests that improve our coverage.

This renames the "module" template to the "application" template, and makes "application" the default. The existing "app" template is now deprecated.

flutter create also now recognizes the type of project in an existing directory, and is able to recreate it without having the template type explicitly specified (although you can still do that). It does this now by first looking in the .metadata file for the new project_type field, and if it doesn't find that, then it looks at the directory structure. Also, the .metadata file is now overwritten even on an existing directory so that 1) the project_type can be added to legacy projects, and 2) the version of Flutter that updated the project last is updated.

I also cleaned up a bunch of things in create_test.dart, added many more tests, and added an example test to the test/ directory in the generated output of the application template.

Fixes #22530
Fixes #22344

* Fix xcode_backend.sh script to support add2app

* Fix ios deployment target. Too old for new Xcode.

* Fix ios host app

* Register plugins with Flutter view

* Prototype

* Fix paths to Flutter library resources

* Invoke pod install as necessary for materialized modules

* Add devicelab test for module use on iOS

* Remove debug output

* Rebase, reame materialize editable

* Add devicelab test editable iOS host app

* Removed add2app test section

* enable lint unnecessary_new

* fix tests

* fix tests

* fix tests

With a fix of a path being printed relative instead of absolute.

This reverts commit 57d78cc7.

* Fix path of ios module template files

* Fix more paths

Add iOS module template

This will enable integration of flutter-views into existing iOS project.

This reverts commit 8be198d8 that broke the build.

Add iOS module template

This will enable integration of flutter-views into existing iOS project.