message: docs: clarify deprecation policy
diff: @@ -24,9 +24,11 @@ maximize the chances of your PR being merged.
  APIs (SDS, CDS, RDS, etc.), and CLI switches. We will also try to not change behavioral semantics
  (e.g., HTTP header processing order), though this is harder to outright guarantee.
  * We reserve the right to deprecate configuration, and at the beginning of the following release
  - cycle remove the deprecated configuration. This means that organizations deploying master should
  - have some time to get ready for breaking changes, but we make no guarantees about the length of
  - time.
  + cycle remove the deprecated configuration. For example, all deprecations between 1.3.0 and
  + 1.4.0 will be deleted soon AFTER 1.4.0 is tagged and released (at the beginning of the 1.5.0
  + release cycle).
  +* This policy means that organizations deploying master should have some time to get ready for
  + breaking changes, but we make no guarantees about the length of time.
  * The breaking change policy also applies to source level extensions (e.g., filters). Code that
  conforms to the public interface documentation should continue to compile and work within the
  deprecation window. We make no guarantees about code or deployments that rely on undocumented
  