Some of the null-safety commands were missing - plumb them through. Ensure that verbose mode shows their output, and clean up the messaging around sound-null-safety.

Fixes #59769

Adds a test that validate each of the null safety supporting build commands has everything plumbed through.

- 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

This option was defaulting to on, which was tickling some benchmarks

* 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

* Reland: [flutter_tool] Fuchsia AOT builds

* Fixes

`flutter build aar`

This new build command works just like `flutter build apk` or `flutter build appbundle`, but for plugin and module projects.

This PR also refactors how plugins are included in app or module projects. By building the plugins as AARs, the Android Gradle plugin is able to use Jetifier to translate support libraries into AndroidX libraries for all the plugin's native code. Thus, reducing the error rate when using AndroidX in apps.

This change also allows to build modules as AARs, so developers can take these artifacts and distribute them along with the native host app without the need of the Flutter tool. This is a requirement for add to app.

`flutter build aar` generates POM artifacts (XML files) which contain metadata about the native dependencies used by the plugin. This allows Gradle to resolve dependencies at the app level. The result of this new build command is a single build/outputs/repo, the local repository that contains all the generated AARs and POM files.

In a Flutter app project, this local repo is used by the Flutter Gradle plugin to resolve the plugin dependencies. In add to app case, the developer needs to configure the local repo and the dependency manually in `build.gradle`:


repositories {
    maven {
        url "<path-to-flutter-module>build/host/outputs/repo"
    }
}

dependencies {
    implementation("<package-name>:flutter_<build-mode>:1.0@aar") {
       transitive = true
    }
}

This reverts commit 11460b83.

`flutter build aar`

This new build command works just like `flutter build apk` or `flutter build appbundle`, but for plugin and module projects.

This PR also refactors how plugins are included in app or module projects. By building the plugins as AARs, the Android Gradle plugin is able to use Jetifier to translate support libraries into AndroidX libraries for all the plugin's native code. Thus, reducing the error rate when using AndroidX in apps.

This change also allows to build modules as AARs, so developers can take these artifacts and distribute them along with the native host app without the need of the Flutter tool. This is a requirement for add to app.

`flutter build aar` generates POM artifacts (XML files) which contain metadata about the native dependencies used by the plugin. This allows Gradle to resolve dependencies at the app level. The result of this new build command is a single build/outputs/repo, the local repository that contains all the generated AARs and POM files.

In a Flutter app project, this local repo is used by the Flutter Gradle plugin to resolve the plugin dependencies. In add to app case, the developer needs to configure the local repo and the dependency manually in `build.gradle`:


repositories {
    maven {
        url "<path-to-flutter-module>build/host/outputs/repo"
    }
}

dependencies {
    implementation("<package-name>:flutter_<build-mode>:1.0@aar") {
       transitive = true
    }
}

This reverts commit 76061c4f.

This reverts commit 98971f3c.

This reverts commit dd65a546.

These are essentially self-inflicted race conditions. Instead of timeouts we're going to try a more verbose logging mechanism that points out when things are taking a long time.

* adding support for android app bundle.

* removing the debug statement.

* fixing formatting and code review changes.

* Revert "fixing formatting and code review changes."

This reverts commit 2041d459f335242555a0b75e445343134c245494.

* Fixing code formatting issues.

* updating review comments fixing comments and spacing.

* changing and to & to rerun the CI and tests.

* updating the comment to re-run the test

updating the comment to re-run the test

* fixing the formatting.

* updating comments to re-trigger build

updating comments to re-trigger build

* enable lint unnecessary_new

* fix tests

* fix tests

* fix tests

This patch eliminates the --preview-dart-2/--no-preview-dart-2 flag,
hardcoding all uses to true. It also defaults all previewDart2 method
parameters to true, where they hadn't yet been.

A series of subsequent patches will eliminate all previewDart2
parameters and the associated code from within the codebase.

* Fixes resulting from audit of issues links

I looked at every link to GitHub in our repo. For cases where we had a TODO that was waiting for a bug to be fixed, and the bug has now been fixed, I applied the pending change. For cases where the link was out of date, I updated the link.

* Update run_test.dart

skip this test again since it failed on linux and macos bots

* Make clean command top level

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

* remove backwards

This makes command validation happen as part of `verifyThenRunCommand()`,
using a newly introduced protected method (`validateCommand()`) rather than
a `commandValidator` property (that subclasses were responsible for manually
invoking).