For communications, add "whether the target has been part of a stable release"

For instance, we might demote or remove a target more quickly and with
less notice if it has never been part of a stable release.

Author: joshtriplett

text/0000-target-tier-policy.md

@@ -384,8 +384,9 @@ requirements. Any proposal for demotion or removal will be CCed to the target
 maintainers, and will be communicated widely to the Rust community before being
 dropped from a stable release. (The amount of time between such communication
 and the next stable release may depend on the nature and severity of the failed
-requirement, the timing of its discovery, and whether the demotion or removal
-can be a planned and scheduled action.)
+requirement, the timing of its discovery, whether the target has been part of a
+stable release yet, and whether the demotion or removal can be a planned and
+scheduled action.)
 
 In some circumstances, especially if the target maintainers do not respond in a
 timely fashion, Rust teams may land pull requests that temporarily disable some
@@ -581,8 +582,9 @@ community, both when initially proposed and before being dropped from a stable
 release. A tier 1 target is highly unlikely to be directly removed without
 first being demoted to tier 2 or tier 3. (The amount of time between such
 communication and the next stable release may depend on the nature and severity
-of the failed requirement, the timing of its discovery, and whether the
-demotion or removal can be a planned and scheduled action.)
+of the failed requirement, the timing of its discovery, whether the target has
+been part of a stable release yet, and whether the demotion or removal can be a
+planned and scheduled action.)
 
 Raising the baseline expectations of a tier 1 target (such as the minimum CPU
 features or OS version required) requires the approval of the compiler and