Introduction of `Waiting for Second Reviewer` tag

## Motivation
PRs commonly fall into a state where they have one approval from an initial reviewer, however no attention from any secondary reviewers. Arguably the most effective mechanism of dissolving PR backlog is exactly to target these sorts of PRs, since the initial approval implies that the underlying quality/status of the work is not too far from mergeable, and the bottleneck lies with a lack of reviewer attention rather than the contributors/authors. Providing a specific tag for this will hopefully make it easier for core developers to find these PRs and push for final merger.

## Current Solution
Currently we have the `Waiting for Reviewer` tag, applied to ~40 PRs, which is generally used to indicate/request extra attention to a PR. This, in combination with a filter for PRs with existing approval ([for example](https://github.com/scikit-learn/scikit-learn/pulls?q=is%3Aopen+is%3Apr+label%3A%22Waiting+for+Reviewer%22+review%3Aapproved)) then results in PRs that, on paper, should also be mergeable with a single extra approval. However there are some flaws to this:

1. The `Waiting for Reviewer` tag is a bit redundant and ill-defined. Every PR, short of approval, is in some sense "waiting for a reviewer", unless it is very specifically waiting on an author to implement changes from existing review. This results in the `Waiting for Reviewer` tag's meaning being muddled.
2. Labeling with the `Waiting for Reviewer` tag is manual. While it could be automated, as it exists right now there is little sense in doing so since -- again -- every PR is in some sense "waiting for a reviewer". This means that coverage is not guaranteed to be thorough and that the label is not exhaustive/surjective.
3. Some PRs which satisfy the above filter cannot be easily merged by another reviewer. In particular, if a PR with the `Waiting for Reviewer` tag and one approval has a review which has requested _changes_ then it would be a false-positive in the sense that the review ought to be continued by the initial reviewer that requested changes once those requests have been addressed.

## Proposed Solution
A very specific `Waiting for Second Reviewer` tag. A PR is eligible for this tag when:
1. It has been approved by one reviewer with commit rights.
2. It has NOT been reviewed by a second reviewer with commit rights (including reviews with `approval`, `comments`, and `changes requested`)

The narrow scope of the tag would also make it relatively simple to automate (hopefully 😄).

## Next Steps (?)
I wonder if we should formalize/clarify the role of `Waiting for Reviewer`, with or without the acceptance of this new tag.

Note: This was discussed in the Drafting Meeting on 10/07/2022: [notes here](https://github.com/Micky774/administrative/blob/drafting_notes/drafting_meetings/2022-10-07)

COMMENT:
> What about a "Waiting for merge" for those PRs like eg #20331... innocent

I am not familiar enough with how common it is for a PR to be ready and just wait for a merge but if it is common enough and it may drastically increase the number of merges and save time for maintainers to scan PRs so I support it

Labels: workflow