Stop documenting None and Any for reviewer_username

What does this MR do and why?

The merge request list APIs describe reviewer_username with two sentences copied from reviewer_id: "None returns merge requests with no reviewers. Any returns merge requests with any reviewer." The parameter has always read its value as a username, so both look for a user with that name and return [] on GitLab.com.

Following the product decision in the issue, this MR drops the two sentences instead of making the wildcards work, so reviewer_username stays a plain username, like assignee_username in REST and reviewerUsername in GraphQL. reviewer_id keeps them, since it accepts both wildcards.

The two sentences go from:

• the reviewer_username description in lib/api/helpers/merge_requests_helpers.rb, which also describes not[reviewer_username];
• the not[reviewer_id] description in the same file: that parameter is declared Integer and refuses None and Any with 400;
• the three reviewer_username rows of doc/api/merge_requests.md, which lists the negated parameters only under not;
• doc/api/openapi/openapi_v3.yaml, regenerated: 12 descriptions, three on each of the four merge request lists.

No behavior changes.

References

Closes #636377 (closed)

Earlier versions of this MR made the wildcards work; the issue thread explains why that changed.

Screenshots or screen recordings

Before	After
Returns merge requests which have the user as a reviewer with the given username. None returns merge requests with no reviewers. Any returns merge requests with any reviewer.	Returns merge requests which have the user as a reviewer with the given username.

How to set up and validate locally

1. In doc/api/openapi/openapi_v3.yaml, find reviewer_username, not[reviewer_username] and not[reviewer_id] under the four merge request lists (global, group, project and deployment): none of them mentions None or Any, and reviewer_id still does.
2. In doc/api/merge_requests.md, the three reviewer_username rows no longer mention them.

How I checked it

On master at 73b11879e427, with the descriptions changed and the committed document untouched, gitlab:openapi:v3:check_docs failed with a diff of exactly those 12 descriptions. After bin/rake gitlab:openapi:v3:generate it reports the document up to date, and the regenerated file differs from master only in them. RuboCop reports no offenses on the helper, markdownlint and Vale report nothing on the changed rows of merge_requests.md, and scripts/lint/commit_linter.rb passes the commit.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.