ls: fix symlink chain target coloring

[ChrisDryden]

When I was reviewing this PR #9006 I tried to do some fuzzing of the existing implementation to see if the PR was implementing any behaviour that was missing and came across that the ls utility was matching all of GNU's coloring except for on nested symlinks.

When looking at what that was the case I saw that it was just a three line fix when compared to the the current implementation

[codspeed-hq]

CodSpeed Performance Report

Merging this PR will not alter performance

_{Comparing ChrisDryden:fix-symlink-chain-coloring (c0b8d66) with main (a1545ef)}

Summary

✅ 282 untouched benchmarks
⏩ 38 skipped benchmarks¹

Footnotes

1. 38 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[ChrisDryden]

Doing a bit more research and theres another pre-existing bug that colors for file extensions is not working, I think there should be a simple fix too but will add some integration tests for that use case too.

[collinfunk]

You only care if it is a link right? Generally file name canonicalization should be avoided, unless it is absolutely necessary. It can become very inefficient:

$ mkdir -p $(yes a | head -n $((1024 * 32)) | tr '\n' '/')
$ while cd $(yes a | head -n 1024 | tr '\n' '/'); do :; done 2>/dev/null
$ for i in $(seq 10); do ln -s . $i; done
$ time ls --color=always -l
[...]
real	0m0.005s
user	0m0.001s
sys	0m0.005s
$ time uu-ls --color=always -l
[...]
real	2m16.180s
user	0m0.596s
sys	2m14.777s