[mdatagen] Expose signal stability in generated docs

[ChrsMark]

As mentioned at #13297 (comment), we need to consider exposing signals' stability per metric. (prior art: #5487)

Right now singal's stability is not exposed by mdatagen in generated metrics' documentation.

In addition, it's not part of the metadata schema:

opentelemetry-collector/cmd/mdatagen/metadata-schema.yaml

Lines 86 to 120 in 18b3b57

	metrics:
	<metric.name>:
	# Required: whether the metric is collected by default.
	enabled: bool
	# Required: metric description.
	description:
	# Optional: extended documentation of the metric.
	extended_documentation:
	# Optional: warnings that will be shown to user under specified conditions.
	warnings:
	# A warning that will be displayed if the metric is enabled in user config.
	# Should be used for deprecated default metrics that will be removed soon.
	if_enabled:
	# A warning that will be displayed if `enabled` field is not set explicitly in user config.
	# Should be used for metrics that will be turned from default to optional or vice versa.
	if_enabled_not_set:
	# A warning that will be displayed if the metrics is configured by user in any way.
	# Should be used for deprecated optional metrics that will be removed soon.
	if_configured:
	# Required: metric unit as defined by https://ucum.org/ucum.html.
	unit:
	# Required: metric type with its settings.
	<sum|gauge>:
	# Required for sum and gauge metrics: type of number data point values.
	value_type: <int|double>
	# Required for sum metric: whether the metric is monotonic (no negative delta values).
	monotonic: bool
	# Required for sum metric: whether reported values incorporate previous measurements
	# (cumulative) or not (delta).
	aggregation_temporality: <delta|cumulative>
	# Optional: Indicates the type the metric needs to be parsed from. If set, the generated
	# functions will parse the value from string to value_type.
	input_type: string
	# Optional: array of attributes that were defined in the attributes section that are emitted by this metric.
	attributes: [string]

I would like to propose to start exposing the metrics' stability in the generated documentation.

My proposal for making this available in Collector's contrib components is:

1. (first PR) expose the stability in the docs conditionally, (if it exists add it) Add stability level info on generated metrics' documentation #13756
2. (in follow-up PR) If no stability is defined add development by default
3. (in follow-up PR) Update the Collector contrib components using the above
4. (in follow-up PR) Consider making the stability a required attribute in the metadata-schema

This is related to #13297 and #11878.