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.

fuchsia_tester.dart still assumes Dart 1. Previously, it ran tests directly
from source, flutter_platform.dart automatically runs a kernel compile when
operating in Dart 2 mode, but this assumes a functional Dart SDK is available
in the artifacts directly, and fuchsia_tester.dart mocks out the artifacts
directory with an empty temp dir.

Remaining work is:
1. Get the frontend server building as a dependency on Fuchsia.
2. Patch fuchsia_tester.dart to use a valid Dart SDK and frontend server.

This also reverts migration to Dart 2 typedef syntax.

This reverts commit 6c56bb24. (#18362)
This reverts commit 3daebd05. (#18316)

* It's time to #deleteDart1 (#18293)

Eliminates support for Dart 1 in flutter_tools, and drops our Dart 1
benchmarks. All commands now run in Dart 1 mode only.

Eliminates --preview-dart-2 / --no-preview-dart-2 support.

* Fix indentation, remove no longer necessary .toList()

* Only push udpated kernel if >0 invalidated srcs

Several benchmarks started failing during kernel compile:
1. Timeouts:
   * commands_test
   * hot_mode_dev_cycle__benchmark
   * run_machine_concurrent_hot_reload
   * service_extensions_test

2. Kernel compiler crash:
   * hot_mode_dev_cycle_linux__benchmark
   * routing_test

3. Unexpected termination:
   * hot_mode_dev_cycle_win__benchmark

This reverts commit ed63e708.

Eliminates support for Dart 1 in flutter_tools, and drops our Dart 1
benchmarks. All commands now run in Dart 1 mode only.

Eliminates --preview-dart-2 / --no-preview-dart-2 support.

Uses the `version` property from the `pubspec.yaml` file to set the corresponding fields in the `local.properties` file respectively in the `Generated.xcconfig` file.

The `--build-name` and `--build-number` options have changed. Now they trump the `version` property from the `pubspec.yaml` file.

If the `version` property is not set and the  `--build-name` and `--build-number` options are not provided, the build command will not change the `local.properties` / `Generated.xcconfig` file.

When running with --local-engine, build single-architecture apps, rather
than what's declared in the Xcode project.

By default, Flutter creates Xcode projects that generate universal
binaries supporting both armv7 and arm64 processors. Since local engine builds
are all single-architecture, override the Xcode project's ARCHS setting
with the appropriate value for the specific engine.

NOTE: this assumes engine paths consistent with those used in the engine
repo: 32-bit iOS engine builds end in _arm, 64-bit builds do not.

* Patch to fix builds with custom targets on iOS simulator. #16787

* Fix for unused import.

* Code review changes applied.

Package projects were erroneously being treated as apps

This updates AppContext per the recommendations in #15352

Fixes #15352

This reverts commit b3e4976c.

* Revert "Revert "Reduce xcodebuild noise #2" (#14641)"

This reverts commit 2d47481f.

* Stop scrapping xcodebuild output, get the right build settings

* clone the command params first

--preview-dart-2.

* Plumb a --strong option through to the front end server and the engine
so that we can run flutter apps in preview-dart-2 and strong mode

* - Address analyzer lint issues
*- correctly set up strong mode option in the case of AOT builds

This reverts commit 8d07d3f6.

* blind wrote everything except the user prompt

* works

* Add some logical refinements

* Make certificates unique and add more instructinos

* print more info

* Add test

* use string is empty

* review notes

* some formatting around commands

* add a newline

* Remove all initial cocoapod traces from flutter create except Podfile

* Make updateXcodeGeneratedProperties parameters named

* review notes

* Revert "Eliminate CocoaPods install step (#8694)"

This reverts commit f4a13bc7.

If the developer is relying on CocoaPods and hasn't done a pod install, we will do it for them. This is needed for a smooth native plugin experience, similar to what Gradle is doing on the Android side.

There's no hard dependency on CocoaPods. We only run pod install if the project uses CocoaPods, so developers are still free to use alternatives if they prefer (and if they don't want to use native plugins).

Fixes #8685
Fixes #8657
Fixes #8526

* Require CocoaPods 1.0.0 or newer.

And make sure we don't get a crash if running `pod install` fails.

* Address review feedback

If the developer is relying on CocoaPods and hasn't done a pod install,
they'll get a build failure indicating the issue.

This also avoids a hard dependency on CocoaPods in the tool and allows
developers to customize their Xcode steps to use alternatives such as
Carthage if they prefer.

Since iOS builds are CocoaPods enabled by default, we should make sure to run `pod install` to get pods wired up before building the app.

Also added a check to `flutter doctor` to verify CocoaPods is installed.

I'm passing FLUTTER_FRAMEWORK_DIR to the `pod install` command, so we can have the app's Podfile link in Flutter.framework as a pod instead of having to copy it over in xcode_backend.sh.

Artifacts are now located in a central place.
This will enable us to downlaod artifacts when we need them (instead of
downloading them all upfront).
This also makes replacing sky_snapshot with gen_snapshot easier.

On flutter run, we update ios/Flutter/Generated.xcconfig with various
Flutter-specific settings required by xcode_backend.sh during a build
from Xcode. These settings need to be present at the time the project is
loaded since Xcode doesn't pick up live updates to these files.

Without these settings, Xcode fails to locate xcode_backend.sh itself,
causing the build to fail until the Xcode project has been closed and
re-opened. This also prevents Xcode's project updater from 'helpfully'
suggesting to clean up and delete the Generated.xcconfig file.

This removes direct file access from within flutter_tools
in favor of using `package:file` via a `FileSystem` that's
accessed via the `ApplicationContext`.

This lays the groundwork for us to be able to easily swap
out the underlying file system when running Flutter tools,
which will be used to provide a record/replay file system,
analogous to what we have for process invocations.