Add the RFC process to CONTRIBUTING.md and issue template (lit#3208)

Author: justinfagnani

.github/ISSUE_TEMPLATE/feature-request.yaml

@@ -2,6 +2,14 @@ name: 🦄 Feature Request
 description: Request a new feature for Lit or a Lit library/tool.
 
 body:
+  - type: checkboxes
+    attributes:
+      label: Should this be an RFC?
+      description: |
+        Lit uses the [Lit RFC Process](https://github.com/lit/rfcs) to propose and discuss substantial chnages. Significant changes should not be opened as feature request issues here, but follow the RFC process at https://github.com/lit/rfcs.
+      options:
+      - label: This is not a substantial change
+        required: true
   - type: dropdown
     id: affected
     validations:

CONTRIBUTING.md

@@ -16,11 +16,17 @@ Please search though open and closed issues to see if a similar issue already ex
 
 Occasionally we'll close issues if they appear stale or are too vague - please don't take this personally! Please feel free to re-open issues we've closed if there's something we've missed and they still need to be addressed.
 
+## RFCs
+
+The Lit project handles "significant" changes and feature requests via our [RFC (Request for Comment) Process](https://github.com/lit/rfcs).
+
+Medium-to-large feature requests should be done via RFC, and feature request issues may be closed after asking that they be submitted as an RFC. If you're wondering whether there's interest in an idea before creating an RFC, file an [RRFC issue](https://github.com/lit/rfcs#before-opening-an-rfc) in https://github.com/lit/rfcs to discuss it.
+
 ## Pull Requests
 
 Pull requests are greatly appreciated! To ensure a smooth review process, please follow these steps:
 
-1.  Make sure there's an open issue that the PR addresses. Add "Fixes #(issue number)" to the PR description.
+1.  Make sure there's an open issue or RFC that the PR addresses. If there's an issue, add "Fixes #(issue number)" to the PR description.
 2.  Please discuss the general shape of the change ahead of time. This can save much time for reviewers and submitters alike. Many times there may be existing ideas on how to handle an issue that are not fully written out, and asking about it will bring out more details.
 3.  All PRs that change behavior or fix bugs should have new or updated tests.
 4.  Try to create a set of descriptive commits that each do one focused change. Avoid commits like "oops", and prefer commits like "Added method foo to Bar".