Mark diff files if they're part of broken symlinks

What does this MR do?

For #223076 (closed)

In order to be able to turn off parts of the UI in certain symlink-related scenarios, we first need to be able to correctly identify those scenarios.

We can already identify current symlinks (file.b_mode === '120000') and past symlinks (file.a_mode === '120000').
Broken symlinks are a much different beast, though, so this MR adds the brokenSymlink property to diff_files.

brokenSymlink is false if we don't immediately have the information that would indicate that:

• There is more than one file with the same file_hash in the full files list
• Any of those duplicates at one point had or currently have the symlink file mode

If brokenSymlink is true, its value is an object whose structure (and internal logic) is available for review in the source code.

Notably, we need to do this work early - right when we receive the file list - because later processing both removes some of this information (because it's not used in the front-end) and does some deduplication. Because of this, this MR adds an early prepareRawDiffFile function that runs before the other basic preparation functions.

Screenshots

N/A, all ~"feature::maintenance"

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

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• [-] Label as security and @ mention @gitlab-com/gl-security/appsec
• [-] The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• [-] Security reports checked/validated by a reviewer from the AppSec team