Adds the following sections to the RFD template: (#22993)

#### Proto Specification
 - This ensures that all api changes are reviewed during the
   design and not in a subsequent PR. This is also more closely
   aligns with the design process we force on interview candidates.
#### Backward Compatibility
 - Forces RFD authors to consider how there changes will interact
   with older clusters and clients. Any migration steps should be
   called out directly in the RFD so that when the feature is rolled
   out there are no surprises.
#### Test Plan
 - Causes the authors to think about what quality assurance measures
   need to be in place to catch regressions before they happen. The
   same testing should also occur prior to the initial release that
   the feature will land in if said release isn't a major release.

rfd/0000-rfds.md

@@ -146,3 +146,27 @@ Describe the UX changes and impact of your design doc.
   recover
 * Consider the UX of configuration changes and their impact on Teleport upgrades
 * Consider the UX scenarios for Cloud users
+
+
+### Proto Specification
+
+Include any `.proto` changes or additions that are necessary for your design.
+
+
+### Backward Compatibility
+
+Describe the impact that your design doc has on backwards compatibility and
+include any migration steps.
+(Non-exhaustive list below.)
+
+* Will the change impact older clients? (tsh, tctl)
+* What impact does the change have on remote clusters?
+* Are there any backend migrations required?
+* How will changes be rolled out across future versions?
+
+### Test Plan
+
+Include any changes or additions that will need to be made to
+the [Test Plan](../.github/ISSUE_TEMPLATE/testplan.md) to appropriately
+test the changes in your design doc and prevent any regressions from
+happening in the future.