doc: project roles: reviewer and assignee clarification

[dleach02]

Clarification of reviewer expectations and role. Emphasis on clarifying when a PR can be closed.

Highlighting reviewers and assignee objective to guide PR to a mergeable state, if possible.

[henrikbrixandersen]

This sounds reasonable and hopefully matches our already existing practice.

[keith-zephyr]

@dleach02 - there was an issue where a reviewer closed the PR of a new contributor. This PR highlights that reviewers shouldn't do this.
Also wanted to highlight that top priority of the assignee is to drive PR to a mergeable state.
@kartben - should the incident been handled with the code of conduct path?
@dleach02 - new contributor added new code along with a reformat of the full file using clang-format and reviewer closed the PR in objection.
@jfischer-no - responsible for closing the PR. @dleach02 - this wasn't the right path.
#73360 is the offending PR.
@fabiobaltieri - blocking a PR is okay, but closing isn't the right approach
@nashif - Gerrit has a feature of -2 vote.
@dleach02 - wants to highlight that escalation process and stalebot are the normal mechanism for closing a PR.
@kartben - having a PR closed is a pretty negative signal to the PR author
@nashif - no objections to the proposed language. But agrees that we have an issue of too many open PRs.
@nashif - we need a mechanism to address PRs that statebot tags, but author reopens it. But this isn't part of the review process. Closing a PR to express disapproval isn't the right approach.
@jfischer-no Did close another PR due to code violation (copied from another project without attribution).
@dleach02 - suggest to still use the escalation process