doc(rfc): Add requirements / non requirements section to RFC. (#1818)

This seems helpful to reviewers (and probably also the author). Motivation is too high level to be able to properly review a design. We need a clear set of requirements to review the design against.

docs/rfc/templates/000-template.md

@@ -21,6 +21,28 @@
 > alternative solutions. In other words, enumerate the constraints you are trying to solve without coupling them too
 > closely to the solution you have in mind.
 
+## Requirements
+
+> What specific requirements does your design need to meet? This should ideally be a bulleted list of items you wish
+> to achieve with your design. This can help everyone involved (including yourself!) make sure your design is robust
+> enough to meet these requirements.
+>
+> Once everyone has agreed upon the set of requirements for your design, we can use this list to review the detailed
+> design.
+
+### Extensibility
+
+> Please also call out extensibility requirements. Is this proposal meant to be extended in the future? Are you adding
+> a new API or set of models that others can build on in later? Please list these concerns here as well.
+
+## Non-Requirements
+
+> Call out things you don't want to discuss in detail during this review here, to help focus the conversation. This can
+> include things you may build in the future based off this design, but don't wish to discuss in detail, in which case
+> it may also be wise to explicitly list that extensibility in your design is a requirement.
+>
+> This list can be high level and not detailed. It is to help focus the conversation on what you want to focus on.
+
 ## Detailed design
 
 > This is the bulk of the RFC.
@@ -60,6 +82,12 @@
 > If we implemented this proposal, how will existing users / developers adopt it? Is it a breaking change? Can we write
 > automatic refactoring / migration tools? Can we provide a runtime adapter library for the original API it replaces? 
 
+## Future Work
+
+> Describe any future projects, at a very high level, that will build off this proposal. This does not need to be
+> exhaustive, nor does it need to be anything you work on. It just helps reviewers see how this can be used in the
+> future, so they can help ensure your design is flexible enough.
+
 ## Unresolved questions
 
 > Optional, but suggested for first drafts. What parts of the design are still TBD?