fix: Make pull request template guidance more evident if it persists (#…

…2271)

The pull request template currently leaves invisible comments which have
occasionally survived into commit messages. This changes those comments
to block quotes to make their existence more evident to reviewers and to
encourage change proposers to delete them as they fill the form.

.github/PULL_REQUEST_TEMPLATE.md

@@ -2,38 +2,41 @@
 v                               ✰  Thanks for creating a PR! ✰
 ☺ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >  -->
 
-<!-- Most PRs should close a specific Issue. All PRs should at least reference one or more Issues. Edit and/or delete the following lines as appropriate (note: you don't need both `refs` and `closes` for the same one): -->
+> Most PRs should close a specific Issue. All PRs should at least reference one or more Issues. Edit and/or delete the following lines as appropriate (note: you don't need both `refs` and `closes` for the same one):
 
-closes: #XXXX
-refs: #XXXX
+Closes: #XXXX
+Refs: #XXXX
 
 ## Description
 
-<!-- Add a description of the changes that this PR introduces and the files that are the most critical to review.  -->
+> Add a description of the changes that this PR introduces and the files that are the most critical to review.
 
 ### Security Considerations
 
-<!-- Does this change introduce new assumptions or dependencies that, if violated, could introduce security vulnerabilities? How does this PR change the boundaries between mutually-suspicious components? What new authorities are introduced by this change, perhaps by new API calls?  -->
+> Does this change introduce new assumptions or dependencies that, if violated, could introduce security vulnerabilities? How does this PR change the boundaries between mutually-suspicious components? What new authorities are introduced by this change, perhaps by new API calls?
 
 ### Scaling Considerations
 
-<!-- Does this change require or encourage significant increase in consumption of CPU cycles, RAM, on-chain storage, message exchanges, or other scarce resources? If so, can that be prevented or mitigated? -->
+> Does this change require or encourage significant increase in consumption of CPU cycles, RAM, on-chain storage, message exchanges, or other scarce resources? If so, can that be prevented or mitigated?
 
 ### Documentation Considerations
 
-<!-- Give our docs folks some hints about what needs to be described to downstream users.  Backwards compatibility: what happens to existing data or deployments when this code is shipped? Do we need to instruct users to do something to upgrade their saved data? If there is no upgrade path possible, how bad will that be for users?  -->
+> Give our docs folks some hints about what needs to be described to downstream users.  Backwards compatibility: what happens to existing data or deployments when this code is shipped? Do we need to instruct users to do something to upgrade their saved data? If there is no upgrade path possible, how bad will that be for users?
 
 ### Testing Considerations
 
-<!-- Every PR should of course come with tests of its own functionality. What additional tests are still needed beyond those unit tests? How does this affect CI, other test automation, or the testnet?  -->
+> Every PR should of course come with tests of its own functionality. What additional tests are still needed beyond those unit tests? How does this affect CI, other test automation, or the testnet? 
 
 ### Compatibility Considerations
 
-<!-- Does this change break any prior usage patterns? Does this change allow usage patterns to evolve? -->
+> Does this change break any prior usage patterns? Does this change allow usage patterns to evolve?
 
 ### Upgrade Considerations
 
-<!-- What aspects of this PR are relevant to upgrading live production systems, and how should they be addressed? -->
+> What aspects of this PR are relevant to upgrading live production systems, and how should they be addressed?
 
-- [ ] Includes `*BREAKING*:` in the commit message with migration instructions for any breaking change.
-- [ ] Updates `NEWS.md` for user-facing changes.
+> Include `*BREAKING*:` in the commit message with migration instructions for any breaking change.
+
+> Update `NEWS.md` for user-facing changes.
+
+> Delete guidance from pull request description before merge (including this!)