fmt: escape ANSI control characters

[carllerche]

Fixes a security vulnerability where ANSI escape sequences in user input could be injected into terminal output, potentially allowing attackers to manipulate terminal behavior through log messages and error displays.

The vulnerability occurred when user-controlled content was formatted using Display ({}) instead of Debug ({:?}) formatting, allowing raw ANSI sequences to pass through unescaped.

Changes:

• Add streaming ANSI escape wrapper to avoid string allocations
• Escape message content in default and pretty formatters
• Escape error Display content in all error formatting paths
• Add comprehensive integration tests for all formatter types

The fix specifically targets untrusted user input while preserving the ability for applications to deliberately include formatting in trusted contexts like thread names.

Security impact: Prevents terminal injection attacks such as title bar manipulation, screen clearing, and other malicious terminal control sequences that could be injected through log messages.

[ziemkowski]

@carllerche can you elaborate on "while preserving the ability for applications to deliberately include formatting in trusted contexts"?

I have hundreds (thousands?) of traces with colored-rs variables that are now escaped in my terminal. What's the proper way to preserve the formatting of those vars?

For example:

info!("This is red: {}", "color test".red());

now escapes the color sequence despite format().with_ansi(use_color):

This is red: \x1b[31mcolor test\x1b[0m

Thanks!

Edit: Looking at the PR, does this still accomplish what you're looking for if \x1b ESC is not escaped? It seems like it wants to escape the bad sequences, not disable escape sequences entirely, no?

Created followup issue: Regression: New tracing-subscriber breaks ANSI color and styling support