Render diagnostics through the terminal library (#7683)

Diagnostic rendering was part of the data model: `Loc::FormatLocation`
and
`Loc::FormatSnippet` wrote plain text to a stream, so no capability,
color, or
terminal width could reach them.

A diagnostic is now one message with labels, contexts, and location
information
attached, and `Diagnostics::Renderer` draws it into a
`Terminal::Buffer`. The
design is in `toolchain/docs/diagnostics_rendering.md` (#7668),
authoring in
`toolchain/docs/diagnostics.md`.

Before:

```
example.carbon:6:3: error: 1 argument passed to function expecting 0 arguments
  Run0(1);
  ^~~~~~~
example.carbon:3:1: note: calling function declared here
fn Run0() {}
^~~~~~~~~~~
```

After:

```
error: 1 argument passed to function expecting 0 arguments
       ╭─┤ example.carbon:6:3
       ┆
     3 │ fn Run0() {}
       · ─────┬─────
       ·      ╰──┤ calling function declared here
       ┆
->   6 │   Run0(1);
       ·   ───────
       ╰────────────
```

`--no-diagnostic-snippets` gives a compact form, `example.carbon:6:3-9`.
File
tests use it; the rendering tests under `toolchain/diagnostics/testdata`
ask for
snippets.

C++ interop diagnostics are data now rather than text Clang drew:
`SemIR::ClangSourceLocId` names a `clang::SourceRange`, and a Clang
location is
marked as the point it names.

`StreamConsumer` moves to a `:renderer` target that `:emitter` does not
depend
on, keeping `common/terminal` out of `consumer.h`. Capabilities come
from the
file behind the error stream, so tests get plain ASCII.

`renderer_fuzzer` draws diagnostics built from fuzzer bytes with every
capability combination, since a shape the renderer doesn't expect must
never be
why the compiler dies while reporting a problem.

TODOs mark the follow-ups: line weights and crossing lines, wrapping
that keeps
a quoted type whole, and ordering diagnostics that share a byte offset.

Also: `IncorrectExtension`'s hint moves into its message, since its note
had no
location of its own, and `strip_noise` in `check_diagnostics.py` blanks
multi-line `#define`s instead of deleting them.

Assisted-by: Claude Code

toolchain/parse/testdata/lambda/lambda.carbon

@@ -20,38 +20,24 @@ var d: auto = fn (ref x: i32) ->? ref i32 { return x; };
 // Tests that the compiler does not crash when a LambdaIntroducer (`fn`)
 // is left unconsumed inside an invalid binary operator sequence.
 
-// CHECK:STDERR: fail_unconsumed_lambda_introducer.carbon:[[@LINE+12]]:10: error: whitespace missing around binary operator [BinaryOperatorRequiresWhitespace]
-// CHECK:STDERR: require j%-fn->>
-// CHECK:STDERR:          ^
+// CHECK:STDERR: fail_unconsumed_lambda_introducer.carbon:[[@LINE+6]]:10: error: whitespace missing around binary operator [BinaryOperatorRequiresWhitespace]
 // CHECK:STDERR:
-// CHECK:STDERR: fail_unconsumed_lambda_introducer.carbon:[[@LINE+8]]:16: error: expected expression [ExpectedExpr]
-// CHECK:STDERR: require j%-fn->>
-// CHECK:STDERR:                ^
+// CHECK:STDERR: fail_unconsumed_lambda_introducer.carbon:[[@LINE+4]]:16: error: expected expression [ExpectedExpr]
 // CHECK:STDERR:
-// CHECK:STDERR: fail_unconsumed_lambda_introducer.carbon:[[@LINE+4]]:16: error: whitespace missing before binary operator [BinaryOperatorRequiresWhitespace]
-// CHECK:STDERR: require j%-fn->>
-// CHECK:STDERR:                ^
+// CHECK:STDERR: fail_unconsumed_lambda_introducer.carbon:[[@LINE+2]]:16: error: whitespace missing before binary operator [BinaryOperatorRequiresWhitespace]
 // CHECK:STDERR:
 require j%-fn->>
-// CHECK:STDERR: fail_unconsumed_lambda_introducer.carbon:[[@LINE+12]]:1: error: expected expression [ExpectedExpr]
+// CHECK:STDERR: fail_unconsumed_lambda_introducer.carbon:[[@LINE+6]]:1: error: expected expression [ExpectedExpr]
 // CHECK:STDERR:
-// CHECK:STDERR: ^
+// CHECK:STDERR: fail_unconsumed_lambda_introducer.carbon:[[@LINE+4]]:1: error: expected `=>` or `{` after return type [ExpectedLambdaBodyAfterReturnType]
 // CHECK:STDERR:
-// CHECK:STDERR: fail_unconsumed_lambda_introducer.carbon:[[@LINE+8]]:1: error: expected `=>` or `{` after return type [ExpectedLambdaBodyAfterReturnType]
-// CHECK:STDERR:
-// CHECK:STDERR: ^
-// CHECK:STDERR:
-// CHECK:STDERR: fail_unconsumed_lambda_introducer.carbon:[[@LINE+4]]:1: error: expected `impls` in `require` declaration [RequireExpectedImpls]
-// CHECK:STDERR:
-// CHECK:STDERR: ^
+// CHECK:STDERR: fail_unconsumed_lambda_introducer.carbon:[[@LINE+2]]:1: error: expected `impls` in `require` declaration [RequireExpectedImpls]
 // CHECK:STDERR:
 
 // --- fail_expected_body.carbon
 
 fn F() {
-  // CHECK:STDERR: fail_expected_body.carbon:[[@LINE+4]]:20: error: expected `->`, `=>`, or `{` [ExpectedLambdaBody]
-  // CHECK:STDERR:   var x: auto = fn ;
-  // CHECK:STDERR:                    ^
+  // CHECK:STDERR: fail_expected_body.carbon:[[@LINE+2]]:20: error: expected `->`, `=>`, or `{` [ExpectedLambdaBody]
   // CHECK:STDERR:
   var x: auto = fn ;
 }
@@ -59,9 +45,7 @@ fn F() {
 // --- fail_expected_body_after_return_type.carbon
 
 fn G() {
-  // CHECK:STDERR: fail_expected_body_after_return_type.carbon:[[@LINE+4]]:27: error: expected `=>` or `{` after return type [ExpectedLambdaBodyAfterReturnType]
-  // CHECK:STDERR:   var x: auto = fn -> i32 ;
-  // CHECK:STDERR:                           ^
+  // CHECK:STDERR: fail_expected_body_after_return_type.carbon:[[@LINE+2]]:27: error: expected `=>` or `{` after return type [ExpectedLambdaBodyAfterReturnType]
   // CHECK:STDERR:
   var x: auto = fn -> i32 ;
 }