Document process and expectations for community PRs

Notes from team discussion:
* We hold the same quality bar for community PRs as we do for team PRs.
* This means PRs must have good test coverage
* We should not hesitate to ask contributors to make changes to meet this bar
* Small trivial changes (such as formatting) may be done by the team as part of merging
* A PR from the community can be treated differently than a team PR. Specifically:
* PRs from the community get a priority boost over other PRs while we are in the development part of the release cycle. This means even if the PR is not something we would otherwise work on we will still spend time on it. The motivation here is to encourage community contributions.
* PRs from the community may be put on hold nearer the end of a release cycle when we are focusing on stabilizing the release.
* We need better documentation on:
* Process and expectations (this issue)
* Architecture and how-to docs for contributors (#1920)

PR process is:
* Initial state: unassigned
* Assigned to a team member with initial thank you note (within 3 days)
* Initial review by team member. (Normally same week or following week.) Outcomes:
* Ready-to-go, but may need to wait before actual merge. Marked as `Approved`.
* Approach looks good, but further changes needed by contributor. Gets the `waiting-for-response` label along with comments asking for specific changes
* Approach looks dubious; more needed than just changes to the code. Gets the `needs-design` label along with comments on next steps
* Team member (or bot) will change state and remove labels as appropriate on response from contributor.
* PRs may be postponed when closing down a release. This is done by setting the milestone and commenting to let the contributor know.