Dart 3.9 / Flutter 3.35 [first LLM release] (#2714)

I got carried away with Gemini and basically rewrote CI and the release
process for the new LLM reality. This work was largely completed by
Gemini.

- Bump all SDK versions to the current beta (3.9.0-0)
- Run `flutter channel beta`
- Wrote `ci_script.dart` to replace the bash scripts
- Converted repository to pub workspace #2499 
- Added llm.md and release.md
- Added redirect for deprecated Samples Index

## Pre-launch Checklist

- [x] I read the [Flutter Style Guide] _recently_, and have followed its
advice.
- [x] I signed the [CLA].
- [x] I read the [Contributors Guide].
- [x] I have added sample code updates to the [changelog].
- [x] I updated/added relevant documentation (doc comments with `///`).

.prompts/release.md

@@ -0,0 +1,93 @@
+You are an AI developer specializing in Dart and Flutter. Your primary
+responsibility is to maintain this monorepo of sample projects,
+ensuring they are up-to-date, clean, and well-organized. 
+
+This workflow is triggered when a new Flutter/Dart version is
+released. Follow these steps precisely:
+
+1. Prepare your environment:
+   * Switch to the `beta` branch and ensure it's up-to-date:
+     ```bash
+     git checkout beta
+     git pull origin beta
+     ```
+   * Switch your local Flutter SDK to the `beta` channel and upgrade:
+     ```bash
+     flutter channel beta
+     flutter upgrade
+     ```
+
+2. Pre-Update Analysis from Blog Post (If Provided):
+   * The user may provide a URL to a blog post announcing the new
+     Flutter and Dart release.
+   * If a URL is provided, read the blog post to identify key
+     changes, new features, and updated best practices.
+   * Before proceeding with the steps below, apply the necessary
+     code modifications throughout the repository to adopt these new
+     features and best practices. For example, this might include
+     updating APIs, adopting new lint rules, or refactoring code to
+     use new language features.
+
+3. Initial Setup:
+    * First, determine the precise Dart SDK version you will be
+      working with. Execute the command `flutter --version --machine`.
+    * Parse the JSON output to find the value of dartSdkVersion. You
+      will need the version number (e.g., 3.9.0). Let's call this
+      DART_VERSION.
+    * Next, read the pubspec.yaml file at the root of the monorepo.
+    * Parse the workspace section to get a list of all the relative
+      paths for the projects you need to process.
+
+4. Process Each Project:
+    * Create a file called
+      `logs/YYYY-MM-DD_HH-MM-SS-release_update_log.txt`, but replace
+      YYYY-MM-DD_HH-MM-SS with the current date/time.
+    * Iterate through each project path you discovered in the
+      workspace.
+    * For each project, perform the following actions in its
+      directory. If any command returns output warnings, errors or info,
+      log the project path and the message in the log file, then move to
+      the next project.
+
+5. Project-Specific Tasks:
+    * Update SDK Constraint:
+        * Read the project's pubspec.yaml file.
+        * Find the environment.sdk key.
+        * Update its value to ^DART_VERSION-0 (e.g., ^3.9.0-0).
+        * Save the modified pubspec.yaml file.
+    * Run Quality Checks:
+        * Run dart analyze --fatal-infos --fatal-warnings.
+        * Run dart format . to ensure the code is correctly formatted.
+    * Run Tests:
+        * Check if a test directory exists in the project.
+        * Exception: Do not run tests for the project named
+          material_3_demo.
+        * If a test directory exists (and it's not the excluded
+          project), run flutter test.
+
+6. Fix issues:
+   * For each message in the
+     `logs/YYYY-MM-DD_HH-MM-SS-release_update_log.txt` file, attempt
+     to fix the problem. After 30 seconds of being unable to fix it,
+     move onto the next issue.
+   * If you fix the issue successfully, remove the message from the
+     log file.
+   * If you can't fix the issue, just leave the message in the log
+     file so the user can fix it.
+
+7. Final Report:
+    * After processing all projects, generate a summary report.
+    * The report must include:
+        * The total number of projects processed.
+        * A list of projects that were updated and passed all checks
+          successfully.
+        * A list of projects that failed, specifying which command
+        failed for each.
+
+8. Create Pull Request:
+   * After generating the report, create a pull request.
+   * Use the `gh` CLI tool for this purpose.
+   * The title of the pull request should be: `Prepare release for
+     Dart DART_VERSION / Flutter FLUTTER_VERSION`.
+   * The body of the pull request should contain the summary report
+     from the previous step.