Audit {`check-run-results`, `regex-error-pattern`, `error-pattern`, `check-stdout`, `normalize-*`, `dont-check-compiler-*`, `run-rustfix`, `rustfix-only-machine-applicable`, `forbid-output`} family of directives

I don't know about other contributors, but I have to look at the source implementation (or trial-and-error) every time I see or try to use one of these compiletest directives. IMO, we should audit the design of these directives, and possibly revamp them entirely.

Concrete confusions:

• check-run-results check both run stderr and stdout and puts them into snapshot files (on bless), then compares the subsequent run stderr and stdout against the snapshot.
• error-pattern doesn't only check stderr (whose stderr? compiler? run?), it can also check stdout (or both??) depending on check-stdout, dont-check-compiler-*, and also it can check also compiler stderr or stdout I think??
• normalize-* (that is not normalize-stdout or normalize-stderr) I believe can simultaneously apply to {compiler,run} {stderr,stdout}.
• run-rustfix will run rustfix and try to apply all non-placeholder suggestions, including non-machine-applicable ones like MaybeIncorrect ones.
• rustfix-only-machine-applicable is like run-rustfix but only tries to apply MachineApplicable suggestions.
• forbid-output is like error-pattern but named completely differently. I don't remember which output pattern of {compiler,run}x{stderr,stdout} it is forbidding.

EDIT:

• regex-error-pattern is like error-pattern but accepts a regex...

Start by reading the compiletest directive implementations for check-run-results, error-pattern, regex-error-pattern, check-stdout, normalize-, dont-check-compiler-, run-rustfix, rustfix-only-machine-applicable, and forbid-output. Trace how each directive selects compiler or run output and how snapshots or rustfix are handled. Done means the directive behavior and naming are audited and the issue's listed ambiguities have a decided, documented resolution.