Add optional ability to approve/reject pull-requests which have already been merged

Currently, once a pull-request has already been merged, there does not seem to be a way to approve or reject it (mark it as "needs more work").  As a result, there are only two modes of operation:

1. PR approval is required - developer is blocked waiting for approval before he can merge.
2. PR approval is not required - developer can merge at will, but ability to approve/reject PRs is lost.

Mode #1 is preferred, but it is too strict and results in slower development progress.  Also, it is not ideal during these days of the pandemic, when many people are working from home, and are working at different times during the day - developers working after core hours are forced to wait until the next day for their PR to be approved so that they could merge their changes. 

The only way to get around this "synchronous" mode of operation is to switch to mode #2 by completely removing PR approval requirement.  That is not ideal, because you completely lose ability to approve/reject PRs because a merged PR can no longer be approved/rejected.

It would be nice if there were a third mode of operation, which is a middle-ground between the two modes above.  It would be nice if PR approval requirement could be removed to allow developers to merge without approval, but still allow reviewers to approve/reject PRs after they've already been merged.  In this optional mode of operation developers could merge at will, and reviewers could review the PRs at a later time, and approve/reject them.  This mode of operation would allow developers and reviewers to operate "asynchronously", and would still allow project-managers to ensure that all code changes have been reviewed and approved prior to a release - they would not release until all merged PRs have been approved (and none of them are tagged as "needs more work").