Fix ResolveLinkTarget for intermediate symlinks

[iamhaseebn]

Fixes #118719

ResolveLinkTarget(..., returnFinalTarget: true) followed a symlink chain only when each complete current path was itself a symbolic link. Kubernetes ConfigMap layouts use an intermediate ..data directory symlink, so resolution stopped before reaching the final target.

This change:

• Resolves relative targets component by component so intermediate symbolic links are followed.
• Preserves lexical absolute targets and dangling final targets.
• Retains the existing 40-link traversal limit.
• Adds shared regression coverage for File, Directory, FileInfo, and DirectoryInfo.

Validation:

• CoreLib build completed with zero warnings and zero errors.
• System.IO.FileSystem tests: 9,618 passed, 0 failed, and 59 expected skips.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[iamhaseebn]

@dotnet-policy-service agree.

[iamhaseebn]

@dotnet-policy-service agree

[teo-tsirpanis]

I wonder if this would solve the failures in dotnet/msbuild#14482.

[iamhaseebn]

Thanks for the pointer. I checked the failing Linux and macOS tests in dotnet/msbuild#14482. This change would not fix them: it follows intermediate links after the input path itself has been identified as a symbolic link. In #14482, File.ResolveLinkTarget(Directory.GetCurrentDirectory(), true) is called on the already-resolved physical directory, so it returns null before that traversal is reached. ResolveLinkTarget is therefore not a general realpath replacement for that non-link input.