Directory based AssemblyClassLoader appears to not do case insensitive directory name compare

[BretJohnson]

Version Used:
Built from Roslyn source on latest main as of 4/9/24

Steps to Reproduce:

(This is copied from the internal Teams thread here https://teams.microsoft.com/l/message/19:d3cb28a5ae614fd8837f2da21f879764@thread.v2/1712726644581?context=%7B%22contextType%22%3A%22chat%22%7D)

Here's another case sensitivity bug (at least I think it's a bug), this time with assembly loading, which @etvorun and I spent time troubleshooting today before finally tracking it down.

Steps: Use the VS Code settings.json below, on Windows. Note that the two extensionPath entries below have the same directory except for case ("Xaml" vs "xaml"). Use Roslyn built with latest main. Launch VS Code and attach the debugger. The Microsoft.VisualStudio.DesignTools.CodeAnalysis.Diagnostics.dll assembly resolve+load happens as expected initially, when the MEF parts are resolved. Then later when code executes that tries to the load the ICodeAnalysisHost type that's inside that assembly, the assembly is loaded a second time, with the same path. Note the the assembly is listed twice in the Modules window screenshot below [see Teams thread for image].

If the directory paths are the same case, this doesn't happen.

{
    "dotnet.server.path": "q:\\src\\roslyn\\artifacts\\bin\\Microsoft.CodeAnalysis.LanguageServer\\Debug\\net8.0\\Microsoft.CodeAnalysis.LanguageServer.dll",
    "dotnet.server.waitForDebugger": true,
    "dotnet.server.extensionPaths": [
"q:\\src\\VS\\out\\binaries\\x86chk\\bin\\netsdk\\Xaml\\CodeAnalysisDiagnostics\\netstandard2.0\\Microsoft.VisualStudio.DesignTools.CodeAnalysis.dll",
"q:\\src\\VS\\out\\binaries\\x86chk\\bin\\netsdk\\xaml\\CodeAnalysisDiagnostics\\netstandard2.0\\Microsoft.VisualStudio.DesignTools.CodeAnalysis.Diagnostics.dll"
    ],
    "workbench.colorTheme": "Default Dark Modern",
    "security.workspace.trust.untrustedFiles": "open"
}

Expected Behavior:

The behavior I'd expect is that the directory names are normalized or compared in a case-insensitive way when the directory is used to control the assembly load context on case-insensitive OSes like Windows. The workaround here isn't hard, but the troubleshooting to find the issue was time consuming so it seems good to fix from that perspective.