doc: contribute: Extend Reviewer Expectations with additional rules

This change was triggered by a review comment linked below:
#83117 (comment)

It extends the current Reviewer Expectations with additional rules
agreed upon by multiple Zephyr contributors in order to simplify and
standardize the decision-making process during PR reviews.

Signed-off-by: Carles Cufi <[email protected]>

doc/contribute/contributor_expectations.rst

@@ -305,10 +305,23 @@ Reviewer Expectations
   they address all non-blocking comments. PR authors should acknowledge every
   review comment in some way, even if it's just with an emoticon.
 
+- Style changes that the reviewer disagrees with but that are not documented as
+  part of the project can be pointed out as non-blocking, but cannot constitute
+  a reason for a request for changes. The reviewer can optionally correct any
+  potential inconsistencies in the tree, document the new guidelines or rules,
+  and then enforce them as part of the review.
+
+- Whenever requesting changes, reviewers must be able to point out the
+  corresponding guideline, rule or rationale in the project's documentation.
+  This does evidently not apply to certain types of requests for changes,
+  notably those specific to the changes being submitted (e.g. the use of a
+  particular data structure or the choice of locking primitives).
+
 - Reviewers shall be *clear* and *concise* what changes they are requesting when the
   "Request Changes" option is used. Requested changes shall be in the scope of
   the PR in question and following the contribution and style guidelines of the
-  project.
+  project. Furthermore, reviewers must be able to point back to the exact issues
+  in the PR that triggered a request for changes.
 
 - Reviewers shall not close a PR due to technical or structural disagreement.
   If requested changes cannot be resolved within the review process, the