Fix infinite loop when rendering merge request file tree

What does this MR do?

If you create an MR which changes files in a directory more than 20 levels deep, the file tree will never render, since the WebWorker(s) responsible for generating the data structure will enter an infinite loop (spiking CPU usage).

This is because the truncation algorithm doesn't handle the case when a path, fully-ellipsised, is still longer than the specified maxWidth.

The depth of 20 mentioned above is due to the fact that a maxWidth of 40 is hard-coded for the tree view. For a path with 21 segments, the string the util would build is …/…/…/…/…/…/…/…/…/…/…/…/…/…/…/…/…/…/…/…/…, which is 41 characters long, so the while condition is never false, leading to the infinite loop.

This adds a condition to handle that case, returning a truncated string that never exceeds the maxWidth, no matter how deep the path is.

There are a few issues(#35815 (closed), #27533 (closed)) about this truncation being less than ideal. For this MR, the intention is to keep the existing behaviour, but fix a pathological case in the simplest way possible.

Example MR demonstrating bug

markrian/project-with-very-deep-path!1 (diffs)

Screenshots

Before	After

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• [-] Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• [-] Style guides
• [-] Database guides
• [-] Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• [-] Tested in all supported browsers
• [-] Informed Infrastructure department of a default or new setting change, if applicable per definition of done