Updates the repo tooling to Dart 3, now that the N-2 version has Dart 3, which allows us to use Dart 3 features (e.g., records) going forward.
To allow the update:
- Removes `break` commands from `switch`es (all done automatically with `dart fix --apply`)
- Replaces mocking of `ProcessResult` with just creating an actual `ProcessResult` since it's a `final` data class and thus can't (but also doesn't need to be) mocked.
For iOS and macOS move fetch deps from explicity running `pub get` and `pod install` to instead run `flutter build x --config-only` which smartly fetches deps and lays down the required native pieces. I didn't guard it on whether certain files are present since the command already has similar guards, and runs pretty fast if the native code has already been generated.
This fixes an issue where `pod install` is run before the Flutter native bits and migrations are run.
Fixes issues seen in the Flutter roll https://github.com/flutter/packages/pull/5792#issuecomment-1876103613
```
Running command: "pod install" in /Volumes/Work/s/w/ir/x/w/packages/packages/camera/camera_avfoundation/example/ios
Analyzing dependencies
[!] CocoaPods could not find compatible versions for pod "Flutter":
In Podfile:
Flutter (from `Flutter`)
Specs satisfying the `Flutter (from `Flutter`)` dependency were found, but they required a higher minimum deployment target.
[!] Automatically assigning platform `iOS` with version `11.0` on target `Runner` because no platform was specified. Please specify a platform for this target in your Podfile. See `https://guides.cocoapods.org/syntax/podfile.html#platform`.
Unable to "pod install"
```
Caused by https://github.com/flutter/flutter/pull/140478
Adds `fetch-deps` support for:
- iOS/macOS dependencies, using `pod install`
- Dart package dependencies, using `pub get`
To make avoid doing extra work in the Dart dependencies step when using this with `*_platform_tests` CI, also adds flags for all of the other platforms, and adds a flag that allows skipping Dart dependencies for any package that doesn't have an example supporting any requested platform. This means that we can pass, e.g., `--windows --supporting-target-platforms-only` to only fetch Dart packages for packages with examples that will be build during the build-and-drive Windows tests.
Adds this as a new step in every platform tests CI task, and in the standard analyze step, so that we will pre-fetch Dart packages (and for iOS/macOS, pods). This won't yet fully eliminate later network access (see https://github.com/flutter/flutter/issues/131204), but will give us early warning on any major failures, such as pub being entirely unreachable from the bots.
- These are marked as an infrastructure step; we'll have to see if this ends up being confusing in practice. If `pub` resolution fails for legitimate reasons, such as a PR that tries to require a version of a package that doesn't exist or that has conflicts, this will cause a failure that is marked as infra. My assumption is that the much more common case is going to be that it is actually an infra failure.
Fixes https://github.com/flutter/flutter/issues/130280
