compiletest: Deficiencies and pitfalls of //@ normalize-* headers

[Zalathar]

These headers allow individual tests to define custom output-normalization rules, so that output snapshots are less sensitive to things like platform differences, line numbers, and timestamps.

Unfortunately, they have a few limitations and pitfalls:

• The value parser for these headers is very lax, and when it does fail to parse, the header is silently ignored.
  • compiletest: Stricter parsing of //@ normalize-* headers #126370
  • Other headers have similar problems: compiletest silently fails on a name-value directive with a known name but missing colon but does not report an error #123760
• The parser doesn't require a colon : after the header name, so the test suite contains an inconsistent mix of with-colon and without-colon rules.
  • Require a colon in //@ normalize-*: test headers #126777
• The rules cannot contain literal double-quote " characters, which is very awkward for some kinds of output (e.g. JSON).
• The parser uses parse_cfg_name_directive to help read the header name, which is sometimes useful (e.g. for defining separate rules for 32-bit and 64-bit), but most of the time it means that tests have to awkwardly write normalize-stderr-test instead of the more intuitive normalize-stderr.
• The rules are applied to both compile output and run output, which is usually not a problem in practice, but can be unexpected.
• Like many other headers, they are only meaningful in ui-mode tests, and are silently ignored if they appear in other kinds of test.

@rustbot label +A-compiletest