Prevent leading whitespace and newline from being collapsed by the html renderer

[BLucky-gh]

Currently ansi_to_html::convert (and I'm assuming to-html would too) preserves newlines in the input strings as newlines in the output string, but newlines are insignificant in html and multiline text gets rendered all on a single line.

The following string:

\n   0: \u{1b}[91mHello, world!\u{1b}[0m\n\nLocation:\n   \u{1b}[35msrc/main.rs\u{1b}[0m:\u{1b}[35m23\u{1b}[0m\n\nBacktrace omitted. Run wit
 h RUST_BACKTRACE=1 environment variable to display it.\nRun with RUST_BACKTRACE=full to include source snippets.

gets converted to

\n   0: <span style='color:var(--bright-red,#f55)'>Hello, world!</span>\n\nLocation:\n   <span style=
 'color:var(--magenta,#a0a)'>src/main.rs</span>:<span style='color:var(--magenta,#a0a)'>23</span>\n\nBacktrace omitted. Run with RUST_BACKTRACE=1 environment variable to display it.\nRun with R
 UST_BACKTRACE=full to include source snippets.

which gets rendered as

rather than the expected

    0: Hello, world!
 
 Location:
    src/main.rs:23
 
 Backtrace omitted. Run with RUST_BACKTRACE=1 environment variable to display it.
 Run with RUST_BACKTRACE=full to include source snippets.

(yes, I'm trying to render color_eyre error messages as html, if you want to replicate this yourself, do format!("{:?}", eyre!("example"))

[BLucky-gh]

I just realized that same goes for leading whitespace. The first and third line are supposed to be indented, but none of that spacing ends up in the final html.

In that case both issues could be handled with a white-space: preserve; in css

[CosmicHorrorDev]

You can wrap the output in a <pre> tag to preserve the formatting. That's what to-html does although it's probably worth documenting somewhere

[BLucky-gh]

Yeah but considering that the output will straight up render incorrectly in regards tothe original text without a <pre> or the like, maybe it would be better to include it in the output directly? Unless there's a significant enough difference between the different options to warrant leaving that to the caller, though I can't think of any reason for such a difference, especially considering that, if I remember correctly, <pre> is usually implemented in browsers with a white-space: preserve; in the user-agent stylesheet, leading to pretty much no difference except when weird choices made in css code are involved, in which case it's on the caller anyways

[CosmicHorrorDev]

I think that's reasonable enough. In to-html's case it's also used to set a class for the entire output <pre class="terminal">, but I believe that could be switched to a <span class="terminal"> instead

@Aloso gets final say though

[Aloso]

I'm not sure. I want the library to be maximally flexible, and adding a pre tag (format!("<pre>{content}</pre>")) is easier than removing it. It just needs to be documented.