Tracing for unmanaged library loading

[elinor-fung]

In .NET 5, we added event tracing for managed assembly loading. The logic for unmanaged library loading is also complicated, involving a fair amount of probing logic and multiple extension points.

We should consider adding tracing for unmanaged library loading. We have had confusion around both why a library could not be found and how / from where a library was found. There isn't really a good way to gain insight into what actually happened - closest is probably procmon/strace. Having tracing could help with understanding such scenarios.

Possible entry points:

• P/Invoke / DllImport
• NativeLibrary.Load (the high-level one)

Interesting actions:

• Load start/end
  • All other events should be correlated with a 'main' load
  • Basic information like requested library, ALC, search path settings, result/error, library path
• Cached images
• Probing
  • We probe (potentially) a lot of different paths based on a matrix of:
    • Platform-dependent name variations
    • Directories specified in NATIVE_DLL_SEACH_DIRECTORIES
    • Directory of the p/invoke assembly (may be skipped by search path settings)
  • Since the OS does the actual load, there is the added complication of OS-dependent behaviour, but tracing would at least get us to the point of 'this is what we gave to the platform and this is the result we got back'.
• Extension points
  • AssemblyLoadContext.LoadUnmanagedDll
  • AssemblyLoadContext.ResolvingUnmanagedDll
  • DllImportResolver

cc @AaronRobinsonMSFT @jkoritzinsky @vitek-karas

[jkoritzinsky]

Moving this to .NET 9 as we've passed feature-complete.