This adds support for non-plugin Gradle validation of packages that use Kotlin Gradle files rather than Groovy gradle files. More work will need to be done to be able to validate plugins that use Kotlin Gradle files, but this is enough for just Android apps.

As a test case for this new validation, this also migrates the `animations` example app to Kotlin Gradle. Rather than doing a manual migration, this was done by:
- Deleting the entire `example android/` directory
- Recreating it on `stable`
- Restoring `android/.pluginToolsConfig.yaml` (without changes)
- Adding a Kotlin version of the Artifact Hub configuration
- Removing the TODO comments that are part of the template Gradle files

Part of flutter/flutter#176065

## Pre-Review Checklist

[^1]: Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling.

It turns out the io.flutter.network-policy is not connected to the engine. Remove any mention of it. Regardless, this *should* control dart sockets and Espresso is only interested in Android native sockets.

Addresses: flutter/flutter#183153

## Pre-Review Checklist

It turns out the io.flutter.network-policy is not connected to the engine. Remove any mention of it. 

Regardless, this *should* control dart sockets and these metadata tags are only added because of Espresso.

Addresses: flutter/flutter#183153

## Pre-Review Checklist

…10732)

Removes guardrails to avoid previously unsupported concurrent camera use cases (this was changed in a later version of CameraX that came after the guards were implemented. See #6608 for details). Fixes flutter/flutter#150387.

As a bonus, also fixes flutter/flutter#157181 by:

1. Using delayed `Future`s instead of calls to `sleep` which I theorize was blocking calls happening on the native side, so the `sleep` calls were not actually giving time for the camera to initialize
2. Ensuring all calls to start video recording have a delay afterwards to, again, give time for the camera to initialize.

I tracked down these fixes by noticing we actually are not surfacing video recording errors; we actually were getting the [ERROR_NO_VALID_DATA](https://developer.android.com/reference/androidx/camera/video/VideoRecordEvent.Finalize#ERROR_NO_VALID_DATA()) error.  Filed an issue to expose all video recording errors like this for easier debugging in the future: flutter/flutter#182960.

## Pre-Review Checklist

**Note**: The Flutter team is currently trialing the use of [Gemini Code Assist for GitHub](https://developers.google.com/gemini-code-assist/docs/review-github-code). Comments from the `gemini-code-assist` bot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed.

[^1]: Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling.

…h iPhone 17 (#11106)

Fixes flutter/flutter#175828

The iPhone 17 family's new camera supports a new pixel format, btp2, which is a lossy, compressed format. At 12MP+ resolutions, AVFoundation drops support for standard YUV/BGRA and strictly outputs this format (e.g., 1651798066 / btp2). The engine renderer expects raw pixels and crashes immediately when given this compressed format. (relevant engine issue: flutter/flutter#182908)

Separately, Centre Stage was introduced for iPhone 17 which is a square sensor. A side effect of this is when we request the highest non-btp resolutions, we previously selected based off total number of pixels. This meant that it was returning a wonky 4032x4032 square. I added a check to only return 4:3 resolutions that aren't square like it did previously, just to avoid previous implementations looking weird. 

## Pre-Review Checklist