[Docs] Mention GitHub commit comments as a possible post-commit review venue

[nikic]

Summary

Mention GitHub commit comments as a possible venue where post-commit review can take place. I believe that commit comments are already being extensively used for this purpose, so this is documenting existing practice.

I've dropped the mention of the development mailing list, because I don't think that's a typical review channel -- it's an escalation route towards the RFC process, but I'd consider that beyond the purview of simple post-commit review.

[tschuett]

Bugzilla is offline?

llvm/docs/CodeReview.rst

 address the issues than comment on the original commit. The original patch
 author, for example, might no longer be an active contributor to the project.
 
 What Tools Are Used for Code Review?
 ------------------------------------
 
 Pre-commit code reviews are conducted on our web-based code-review tool (see
 :doc:`Phabricator`). Post-commit reviews can be done on Phabricator, by email
-on the relevant project's commit mailing list, on the project's development
-list, or on the bug tracker.
+on the relevant project's commit mailing list, using commit comments on GitHub,
+or on the bug tracker.
 
 When Is an RFC Required?
 ------------------------
 
 Some changes are too significant for just a code review. Changes that should
 change the LLVM Language Reference (e.g., adding new target-independent
 intrinsics), adding language extensions in Clang, and so on, require an RFC
 (Request for Comment) email on the project's ``*-dev`` mailing list first. For