`ls`: Consider simplifying column computation (and not use `ansi_width`)

In #7801, we added some complicated logic to lazily evaluate line length (i.e. ansi_width), but maybe we can simplify that logic instead.

I think we can use the byte offset instead, because we add this byte if it could possibly wrap, so we only need a lower bound on adding it. That should be cheaper to compute than the ansi_width computation.
I can even show that GNU does that. I did this in a terminal that fit the filename easily, but because emojis consist of many bytes, GNU will add the byte:

touch 🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀.foo
env TERM=xterm  LS_COLORS="*.foo=0;31;42" TIME_STYLE=+T ls  --color=always 🦀
🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀.foo

I checked this by piping into bat -A.

Originally posted by @tertsdiepraam in https://github.com/uutils/coreutils/pull/7801#discussion_r2051795120

The issue points to ls column computation and the ansi_width-based logic discussed in #7801; begin by reading that change and locating the current path. Compare the proposed byte-offset approach with the emoji example. Done means simplifying the computation without regressing the illustrated wrapping behavior.