In keeping with the discussions about JIRA, Gitlab, and issue management
(e.g.  https://lab.civicrm.org/infrastructure/ops/issues/817), this change
would revise the "Review Standards".  Instead of specifically requiring
*a JIRA issue* for every PR, it requires *a public explanation* (which can be
provided by JIRA, Gitlab, etc).

Note: This change tries to be the smallest reasonable alteration to the
review criteria that accomodates Gitlab.  However, perhaps we could make it
better -- e.g.  by providing examples of good and bad explanations?

Related: https://github.com/civicrm/civicrm-core/blob/master/.github/PULL_REQUEST_TEMPLATE.md

A person is not a PHP script.

Minor formatting issues, remove stray backslashes

The purpose of the intro paragraph is to prep the reader to see several
different test types/tools.  So it...  should probably use the word "test"
somewhere.

Missing ; and .

If I disagree with using the "NFC" label, I'd like to be able to quickly
reference a link that explains the rationale and provides examples.

Minor tweaks, typos etc

"Security Doucmentation" --> "Security Documentation"

Some more details about creating a settings page for an extension.

Three changes here:
 * Sort criteria in the same order across all three templates.
 * For meta-instructions, use the Markdown/HTML comment notation.
 * For `r-run`, we really don't want boilerplate. Remove the boilerplate.

The DEL workflow produces more readable output.

This makes it easier to find for people who come to the page just
looking for this one thing, which should be a common use-case of this
content.

There was confusion in some docs about `r-user` vs `r-users`. Standardize on `r-user`.

The name `r-technical` was bit more verbose than all the other abbreviations. `r-tech` looks like it'll fit better.

style guide ref:
https://docs.civicrm.org/dev/en/latest/documentation/style-guide/#hackable-urls