chore: Update back-compact / forward-compat defs

Amend the definitions of "backward compatibility" and
"forward compatibility" in the "Compatibility and Migration"
section of the RFD template to more clearly explain
requirements for RFD writers.

In the future we'd like this section to be more rigorous,
and ideally to provide a detailed breakdown of what kinds
of changes in the schema are considered "breaking," but
the versioning rules for the CVE Record Format aren't
sufficiently defined yet.

I recommend developing an RFD to solidify the versioning
rules, and then amending the template to require greater
rigor around compatibility in this section.

Signed-off-by: Andrew Lilley Brinker <abrinker@mitre.org>

Author: alilleybrinker

rfds/_TEMPLATE.md

@@ -75,11 +75,16 @@ compatibility.
 
 To address backward compatibility, explain if and how your proposal would
 impact users of the schema's ability to parse existing CVE records produced
-under prior versions of the CVE Record Format.
+under prior versions of the CVE Record Format. Note that CVE records returned
+by CVE Services are automatically updated to use new schema versions, so
+interaction with historic CVE records would only arise for records stored and
+obtained outside of CVE Services.
 
 To address forward compatibility, explain if current users of the schema would
-be able to accept all, some, or none of the records produced with the schema as
-modified by your proposal.
+be able to parse all, some, or none of the records produced with the schema as
+modified by your proposal. If CVE consumers would need to amend their existing
+parsers for CVE records be able to parse records produced under the new schema,
+describe what amendments would be necessary for them.
 
 These explanations must specifically answer the following questions: