Improve wording in Rationale as suggested by AA-Turner

> The current wording is in the rationale section, which is
> setting out the justification for the proposal. To me, it
> seems odd to phrase it "We need <feature> because <thing>
> requires <requirement>, but we don't guarantee requirement.
>
> My suggested rephrasing more explicity spells out that we
> want to support <thing> properly, there is a reason the
> current state doesn't work (no guarantees at an API level
> of stability), and hence <feature> is needed that provides
> those guarantees.

- #2559 (comment)

Author: encukou

pep-0689.rst

@@ -29,9 +29,12 @@ The Python C-API is currently divided into `three tiers <https://devguide.python
   <387>`, and requires deprecation warnings before changes
 - Private (internal) API, which can change at any time.
 
-We need a tier between Public and Private to accommodate tools like
-advanced debuggers and JIT compilers, which need access to CPython
-internals but assume the C-API they use does not change in patch releases.
+Tools requring access to CPython internals (e.g. advanced
+debuggers and JIT compilers) are often built for minor series releases
+of CPython, and assume that the C-API interals used do not change
+in patch releases. To support these tools, we need a tier between the
+Public and Private C-API, with guarantees on stability throughout
+the minor-series release.
 
 
 Setting Stability Expectations