Update breaking changes guide with how to use reusable content blocks (#68116)

## What
<!--
* Describe what the change is solving. Link all GitHub issues related to
this change.
-->

Updated the guide AJ produced for breaking connector changes. Adds
instructions to use the block of generic connector upgrade information
that can be added dynamically.

## How
<!--
* Describe how code changes achieve the solution.
-->

## Review guide
<!--
1. `x.py`
2. `y.py`
-->

## User Impact
<!--
* What is the end result perceived by the user?
* If there are negative side effects, please list them. 
-->

## Can this PR be safely reverted and rolled back?
<!--
* If unsure, leave it blank.
-->
- [x] YES 💚
- [ ] NO ❌

---------

Co-authored-by: Patrick Nilan <[email protected]>

Author: ian-at-airbyte

docs/platform/connector-development/connector-breaking-changes.md

@@ -53,9 +53,9 @@ The breaking change metadata allows you to specify narrowed scopes, and specific
 
 Your migration guide must be created as a separate file at `docs/integrations/{sources|destinations}/{connector-name}-migrations.md`. The guide should be detailed and user-focused, addressing the following for each breaking change version:
 
-- **WHAT** - What changed: Specifically, what is fixed or better for the user after this change?
-- **WHY** - Why did we make this change? (API improvements, upstream deprecation, bug fixes, performance improvements).
-- **WHO** - Which users are affected? Be specific about streams, sync modes, or configuration options that are impacted.
+- **WHAT** - What changed? Specifically, what's fixed or better for the user after this change?
+- **WHY** - Why did you make this change? (API improvements, upstream deprecation, bug fixes, performance improvements).
+- **WHO** - Which users does this change affect? Be specific about streams, sync modes, or configuration options that are impacted.
 - **STEPS** - Exact steps users must take to migrate, including when to take them (before/after upgrade, before/after first sync).
 
 Your migration guide can be as long as necessary and may include images, code snippets, SQL examples, and compatibility tables to help users understand and execute the migration.
@@ -69,6 +69,42 @@ Review these examples to understand the expected format and level of detail:
 - [Stripe Migration Guide](/integrations/sources/stripe-migrations) - Detailed sync mode and cursor field changes
 - [Snowflake Destination Migration Guide](/integrations/destinations/snowflake-migrations) - Use case-based migration paths
 
+### Reusable Migration Content
+
+It's desirable for a migration guide to instruct your reader how to plan for, execute, and clean up after an upgrade. This information is applicable to most upgrades for most connectors, and you shouldn't normally need to document it. A reusable content snippet exists at `docusaurus/static/_migration_guides_upgrade_guide.md`. It contains generic upgrade information shared by every connector, and you can import it into your migration guide seamlessly.
+
+This avoids duplicating content, increases the likelihood that documentation remains up-to-date, and makes it easier to author your migration guide. The only migration content you should author in a bespoke fashion should focus on the specifics of this connector and connector version.
+
+#### How to use the snippet
+
+1. Import the reusable content into your doc as a React component.
+
+    ```js title="mydoc.md"
+    import MigrationGuide from '@site/static/_migration_guides_upgrade_guide.md';
+    ```
+
+2. Display it.
+
+    ```js title="mydoc.md"
+    <MigrationGuide />
+    ```
+
+#### Example usage
+
+```md title="asana-migrations.md"
+import MigrationGuide from '@site/static/_migration_guides_upgrade_guide.md';
+
+# Asana Migration Guide
+
+## Upgrading to 1.0.0
+
+Here are the details of this breaking change that are specific to Asana.
+
+## Connector upgrade guide
+
+<MigrationGuide />
+```
+
 ## Breaking Change Metadata Requirements
 
 When adding a `breakingChanges` entry to your connector's `metadata.yaml` file, you must provide two critical fields: