[chore] Document scalability, performance and resiliency requirements for stable components (#12994)

<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
<!-- Issue number if applicable -->

This updates the stability requirements to require certain benchmarking,
testing and documentation to ensure scalability, resiliency and
performance expectations are documented at a minimum level.

To operationalize this, I will work on:
- Adding automated context propagation tests for components for which it
is easy to do so (connectors and processors)
- Adding a new section to the table with a link to the latest
benchmarking results.

#### Link to tracking issue

Fixes #11866
Fixes #11868
Fixes #11593

Author: mx-psi

docs/component-stability.md

@@ -89,13 +89,14 @@ components apply to stable when it comes to configuration changes.
 
 #### Testing requirements
 
-Stable components MUST have a test coverage that exceeds the highest between 80% coverage and the
-repository-wide minimum. The unit test suite SHOULD cover all configuration options. The coverage
-MUST be shown as part of the component documentation.
-
-Stable components SHOULD provide at least one example configuration that works for each stable
-signal, and have at least one lifecycle test that tests the component's initialization with a valid
-configuration. Said configuration should also be shown in the component documentation.
+Stable components MUST have a comprehensive test suite. In particular they MUST have:
+1. A **test coverage** that exceeds the highest between 80% coverage and the repository-wide
+minimum. The unit test suite SHOULD cover all configuration options. The coverage MUST be shown as
+part of the component documentation.
+2. At least one **lifecycle test** that tests the component's initialization with a valid
+   configuration and ensures proper context propagation if applicable.
+3. At least one **benchmark test** for each stable signal. The component's documentation MUST
+   include a link to the latest run of benchmark results.
 
 #### Documentation requirements
 
@@ -108,6 +109,9 @@ Stable components should have a complete set of documentation, including:
   what they provide.
 - Compatibility guarantees with external dependencies including the versions it is compatible with
   and under what conditions.
+- Guidance related to the component's usage in production environments, including how to scale a deployment of this component properly if it needs special considerations.
+- If stateful, how to configure the component to use persistent storage and how to gracefully
+  shutdown and restart the component.
 - Warnings about known limitations and ways to misuse the component.
 
 Receivers that produce a fixed set of telemetry should document the telemetry they produce,
@@ -300,6 +304,7 @@ To graduate any signal from alpha to beta on a component:
 
 To graduate any signal from beta to stable on a component:
 1. The component MUST have at least three active code owners.
+2. The component benchmark results MUST have been updated within the last 30 days and published in the component's README.
 3. Within the 60 days prior to the graduation request, the code owners MUST have reviewed and
    replied to at least 80% of the issues and pull requests opened against the component. This
    excludes general PRs or issues that are not specific to the component itself (e.g. repo-wide API