Fix truncate_str panicking mid-character without ansi-parsing

[lenamonj]

truncate_str panics on multi-byte input when built without ansi-parsing:

// default-features = false, features = ["std", "unicode-width"]
console::truncate_str("你好世界", 5, "");
// panicked at src/utils.rs:978:15:
// end byte index 5 is not a char boundary; it is inside '好'

The not(ansi-parsing) branch slices with &s[..width.saturating_sub(tail.len())]: a byte offset used as a column count, and the tail charged by len() instead of its display width. It now walks chars against a budget of width - str_width(tail) and cuts on a boundary, matching the ansi-parsing branch.

That also merges char_width's two definitions into one gated on unicode-width. The not(ansi-parsing) copy returned 1 for every char, so it disagreed with str_width in builds that enable unicode-width.

Tests are gated per feature state like the ones beside them; both fail on main with the panic above. All seven make test configurations pass, plus cargo fmt --check and cargo clippy.

Two related bugs in the same class are not in this PR: read_line_initial_text mixes initial.len() with a char index (non-ASCII initial text discards typed input), and Windows read_secure backspace uses rv.truncate(rv.len() - 1). Happy to file either separately.

Found with AI assistance; verified and reviewed by me.

[lenamonj]

Fixed in the force-push above: the test asserted display widths in every configuration, but char_width is 1 per char without unicode-width. Now gated per feature state. All seven make test configurations pass.

[djc]

Please reword all the slop in your description and comments.

[lenamonj]

Done, both reworded.

[djc]

Much better, thanks!