irverify: naming content violations quote ill-formed bytes into their own message

[OmarAlJarrah]

Summary

checkDiagnostics refuses to repeat ill-formed bytes: ir/diagnostic-invalid-utf8's message is
the fixed string "diagnostic message is not valid UTF-8", and its doc comment says why — the
report is what a reader looks at, so putting the bad bytes back into it helps nobody.

appendContentViolations does the opposite. Every message it builds interpolates the name it
objects to:

Message: channel + " " + name + " carries casing; store neutral words",

So a Canonical or Hint carrying ill-formed UTF-8 produces a Violation whose own Message is
ill-formed:

"canonical name caf\xe9 carries casing; store neutral words"
"name hint caf\xe9 is not a word sequence; split it on every non-word character"

Observed while adding ir/naming-invalid-utf8 in #361 — a test asserting the new rule quoted
nothing caught these two neighbours quoting everything.

Why it is not simply a bug

Quoting the spelling is the right default for these three rules. They are about how a name is
spelled, and a message that says "canonical name carries casing" without saying which name leaves
the reader to go find it. ir/naming-invalid-utf8 can decline to quote precisely because its
complaint is not about the spelling.

So the question is what a content rule should do in the one case where the spelling is
unprintable, and the answer is not "never quote".

Suggested shape

Quote a sanitized rendering rather than the raw value — strconv.Quote escapes an invalid byte as
\xe9 and is already how this repo's tests display these strings. That keeps the reader informed,
keeps the report well-formed, and needs no per-rule decision about whether the name is safe.

Worth checking the same question across every Violation message that interpolates spec-derived
text, not only these three:

$ grep -rn 'Message:' ir/irverify/*.go | grep -v '_test'