Update pull request template (#1162)

The pull request template is a bit confusing and is prone to creating
extra noise.

* After the line "PR Title", the reader is instructed to fill out a
  description of changes, and then there is the line "Description". If
  "PR Title" and "Description" are section headers, one would think a
  description would be placed within the "Description" section, not the
  "PR Title" section.
* The "Description" section holds an example, but most PRs I've seen do
  not clear this section out appropriately, but leave unfilled sections
  untouched.
* This PR template is inconsistent with the one we use for the module
  template. While of course this repo is shared among multiple teams, we
  should strive to keep it somewhat more consistent.

.github/pull_request_template.md

@@ -1,52 +1,46 @@
+## Description
+
 <!--
-Thanks for your contribution!
+Thanks for your contribution! Take a moment to answer these questions so that reviewers have the information they need to properly understand your changes:
 
-Please ensure that any applicable requirements below are satisfied before submitting this pull request. This will help ensure a quick and efficient review cycle.
+* What is the current state of things and why does it need to change?
+* What is the solution your changes offer and how does it work?
+* What packages are you updating?
+* Are you introducing a breaking change to a package (renaming or removing a part of a public interface)?
 -->
 
-**PR Title**
-
-- A brief description of changes. If the PR has breaking changes add `BREAKING:`
-  to the start of the PR title.
-
-**Description**
-
-_Itemize the changes you have made into the categories below_
-
-- BREAKING:
-
-  - _Describe the how to patch your code for the breaking changes_
-  - _Create PRs for other projects with patches to breaking changes_
-
-- FIXED:
-
-  - _Describe the fix/bug addressed_
+## Changes
 
-- CHANGED:
-
-  - _Describe the change you have made to existing functionality_
-
-- REMOVED:
-
-  - _Describe functionality removed and why_
-
-- ADDED:
+<!--
+Pretend that you're updating a changelog. How would you categorize your changes?
 
-  - _Describe functionality added and why_
+CATEGORY is one of:
 
-- DEPRECATED:
+- BREAKING
+- ADDED
+- CHANGED
+- DEPRECATED
+- REMOVED
+- FIXED
 
-  - _Describe what was deprecated and why_
+(Security-related changes should go through the Security Advisory process.)
+-->
 
-- SECURITY:
+- **<CATEGORY>**: Your change here
+- **<CATEGORY>**: Your change here
+- **<CATEGORY>**: Your change here
 
-  - _These should not be in a standard PR and addressed using the Security Advisory process_
+## References
 
-**Checklist**
+<!--
+Are there any issues or other links that reviewers should consult to understand this pull request better? For instance:
 
-- [ ] Tests are included if applicable
-- [ ] Any added code is fully documented
+* Fixes #12345
+* See: #67890
+-->
 
-**Issue**
+## Checklist
 
-Resolves #???
+- [ ] I've updated the test suite for new or updated code as appropriate
+- [ ] I've updated documentation for new or updated code as appropriate (note: this will usually be JSDoc)
+- [ ] I've highlighted breaking changes using the "BREAKING" category above as appropriate