Windows Server Data Deduplication Incorrectly Interpreted as Symlinks

### Description of the bug:

# Problem
When running Bazel on a Windows server with Data Deduplication turned on (see https://learn.microsoft.com/en-us/windows-server/storage/data-deduplication/overview), https://github.com/bazelbuild/bazel/blob/478c7e06924a4f277d2252610b8f675fc6faa6f7/src/main/native/windows/file.cc#L95 will interpret deduplicated files as symlinks. When the file is then read, https://github.com/bazelbuild/bazel/blob/478c7e06924a4f277d2252610b8f675fc6faa6f7/src/main/native/windows/file.cc#L533 will return "Unknown link type".

`IsSymlinkOrJunction` only checks if the file is a reparse point, not that the reparse point is a symlink or junction. All reparse points listed [here](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/c8e77b37-3909-4fe6-a4ea-2b9d423b1ee4) except for `IO_REPARSE_TAG_SYMLINK` and `IO_REPARSE_TAG_MOUNT_POINT` (which are handled explicitly in `ReadSymlinkOrJunction`) are handled incorrectly.

This issue was brought up in https://github.com/bazelbuild/bazel/issues/11237 but for `IO_REPARSE_TAG_DFS` reparse points. In it, there was a suggestion to change `IsSymlinkOrJunction` to look at the reparse tag in addition to the reparse point flag, but it was never committed. I believe this change would address the problem.

# Context
My company wants to use Bazel to compile their product, however we are intermittently getting error like:
```
[0 / 5] [Prepa] BazelWorkspaceStatusAction stable-status.txt
ERROR: {obfuscated path}/BUILD:16:10: {obfuscated target}: error reading file '{obfuscated path}': Cannot read link (name={obfuscated path}): unknown link type
ERROR: {obfuscated path}/BUILD:16:10: 1 input file(s) are in error
Target {obfuscated target} failed to build
```
After investigating, all files that are reported as "unknown link type" have been deduplicated by Windows after the deduplication delay.

This is preventing us from adopting Bazel, as we can't have intermittent errors like this. We can't just turn off file deduplication because it saves us a very appreciable amount of disk space.

### Which category does this issue belong to?

Core

### What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

On a Windows Server machine with deduplication turned on for a volume, build anything with Bazel after the files have been deduplicated (there is a configurable delay for deduplication).

### Which operating system are you running Bazel on?

Windows Server

### What is the output of `bazel info release`?

release 6.1.1

### If `bazel info release` returns `development version` or `(@non-git)`, tell us how you built Bazel.

_No response_

### What's the output of `git remote get-url origin; git rev-parse master; git rev-parse HEAD` ?

```text
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
```

### Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.

This does not appear to be a regression. It just never worked.

### Have you found anything relevant by searching the web?

https://github.com/bazelbuild/bazel/issues/11237
https://github.com/bazelbuild/bazel/issues/7907

### Any other information, logs, or outputs that you want to share?

_No response_

Start in src/main/native/windows/file.cc at IsSymlinkOrJunction and ReadSymlinkOrJunction, then review the linked Windows reparse-tag documentation and issue 11237. Reproduce on a Windows Server volume with Data Deduplication enabled after files are deduplicated. Done means deduplicated files are not reported as unknown link types and Bazel can read them successfully.

Written by the indexing model from the issue text.