fix (#6586): Set a length limit

[algosul]

Fixes #6586

After formatting, the line_start may be longer than line. For example, "> >" (3 characters) will become "> > " (4 characters) after formatting.

[ytmimi]

Can we prevent "> >" from getting reformatted as "> > "? Based on your comment that seems like the root of the problem, but the current solution tries to resolve it after the fact, or am I missing something?

[algosul]

Can we prevent "> >" from getting reformatted as "> > "? Based on your comment that seems like the root of the problem, but the current solution tries to resolve it after the fact, or am I missing something?我们能否防止 “> >” 被重新格式化为 “> > ”？根据您的评论，这似乎是问题的根源，但当前的解决方案试图在事后解决它，还是我遗漏了什么？

I'm very sorry that I didn't explain it clearly.

But this is the best solution I can think of.

In ItemizedBlock::new (approximately 490 lines)

 fn new(line: &str) -> Option<ItemizedBlock> {
    let marker_length = ItemizedBlock::get_marker_length(line.trim_start())?;
    let space_to_marker = line.chars().take_while(|c| c.is_whitespace()).count();
    let mut indent = space_to_marker + marker_length;
    let mut line_start = " ".repeat(indent);

    // Markdown blockquote start with a "> "
    if line.trim_start().starts_with('>') {
        // remove the original +2 indent because there might be multiple nested block quotes
        // and it's easier to reason about the final indent by just taking the length
        // of the new line_start. We update the indent because it effects the max width
        // of each formatted line.
        line_start = itemized_block_quote_start(line, line_start, 2); // <--- Formatting has been applied here.
        indent = line_start.len().min(line.len()); // <--- Changed line
    }
    Some(ItemizedBlock {
        lines: vec![line[indent..].to_string()], // <--- The line that causes panic: `line[indent..]` might be access violation
        indent,
        opener: line[..indent].to_string(),
        line_start,
    })
}