[browser][Windows] Assembly reference with Unicode path cannot be resolved on Windows

[ilonatommy]

Fixes #110482

We are enabling long paths in helix but WasmBuildTests are running inside of docker (image: mcr.microsoft.com/dotnet-buildtools/prereqs:windowsservercore-ltsc2022-helix-webassembly). We could edit the image to enable the long paths but that could break other tests that are specifically testing long paths. For this test, we can work it around by shortening the assembly path and log an issue about this problem.

[ilonatommy]

The path it's complaining about is 262 chars:
C:\helix\work\workitem\e\wbt artifacts\nuget\blz_dllimp_Release_鿀蜒枛遫䡫煉build_then_publish_Release_False_qrkfikty_pdq_鿀蜒枛遫䡫煉\microsoft.extensions.configuration.fileextensions\10.0.0-alpha.1.24569.15\lib\net10.0\Microsoft.Extensions.Configuration.FileExtensions.dll
The limit of chars for assembly name is 260. Locally, when testing, MAX_PATH is disabled. This would explain why the failures are restricted to CI. It is possible that on the helix machine, the max path limitation is not disabled.

[ilonatommy]

LongPathsEnabled check on Windows's machine:
log

long path enabled -> False

[ilonatommy]

The change did not shorten the path enough for some .dlls, e.g. C:\helix\work\workitem\e\wbt artifacts\nuget\dllimp_Release_鿀蜒枛遫䡫煉build_then_publish_Release_False_on1vy5gd_4mf_鿀蜒枛遫䡫煉\microsoft.extensions.dependencyinjection.abstractions\10.0.0-alpha.1.24569.15\lib\net10.0\Microsoft.Extensions.DependencyInjection.Abstractions.dll. It's best to revert the shortening and see if dotnet/dotnet-buildtools-prereqs-docker#1328 fixed it.