Clarify experimental additions to Stable components (#597)

The Entities SIG is planning a backward-compatible addition to the Resource,
see the prototype here: tigrannajaryan#2

The change is compliant with existing stability requirements in this repository.

However, our stability definition does not specify how such experimental additions
to stable signals are expected to be done and what happens during and after
the experiment.

This PR adds more clarity in the process and further refines the stability
definition to reinforce our strong commitment ot OTLP's stability.

README.md

@@ -83,14 +83,47 @@ All the additive changes above must be accompanied by an explanation about how
 new and old senders and receivers that implement the version of the protocol
 before and after the change interoperate.
 
-No guarantees are provided whatsoever about the stability of the code that
-is generated from the .proto files by any particular code generator.
-
 ## Experiments
 
-In some cases we are trying to experiment with different features. In this case,
-we recommend using a "development" sub-directory instead of adding them to any
-protocol version. These protocols should not be used, except for
-development/testing purposes.
+### New Experimental Components  
+
+Sometimes we need to experiment with new components, for example to add a
+completely new signal to OpenTelemetry. In this case, to define new experimental
+components we recommend placing new proto files in a "development" sub-directory.
+Such isolated experimental components are excluded from
+above [stability requirements](#stability-definition).
+
+We recommend using
+`Development`, `Alpha`, `Beta`, `Release Candidate`
+[levels](https://github.com/open-telemetry/opentelemetry-specification/blob/main/oteps/0232-maturity-of-otel.md#maturity-levels)
+to communicate different grades of readiness of new components.
+
+Experimental components may be removed completely at the end of the experiment,
+provided that they are not referenced from any `Stable` component.
+
+Experiments which succeed, require a review to be marked `Stable`. Once marked
+`Stable` they become subject to the [stability requirements](#stability-definition).
 
-Another review must be conducted for in-development protocols to join the main project.
+### Experimental Additions to Stable Components
+
+New experimental fields or messages may be added in `Development` state to `Stable`
+components. The experimental fields and messages within `Stable components` are subject
+to the full [stability requirements](#stability-definition), and in addition, they must be
+clearly labeled as `Development` (or as any other non-`Stable` level) in the .proto file
+source code.
+
+If an experiment concludes and the previously added field or message is not needed
+anymore, the field/message must stay, but it may be declared "deprecated". During all
+phases of experimentation it must be clearly specified that the field or message may be
+deprecated. Typically, deprecated fields are left empty by the senders and the recipients
+that participate in experiments must expect during all experimental phases (including
+_after_ the experiment is concluded) that the experimental field or message has an
+empty value.
+
+Experiments which succeed, require a review before the field or the message is marked
+`Stable`.
+
+## Generated Code
+
+No guarantees are provided whatsoever about the stability of the code that
+is generated from the .proto files by any particular code generator.