Fix native library resolution for dotnet tools on Linux

[Happypig375]

Problem

ClangSharpPInvokeGenerator fails to load libclang and libClangSharp on Linux when run as a dotnet tool, even though the RID-specific packages (e.g. ClangSharpPInvokeGenerator.linux-x64) bundle these libraries alongside the executable.

Root causes

1. Broken TryResolveClang method: The custom DllImportResolver tried hardcoded versioned SONAMEs (libclang.so.20, libclang-20) that don't match the LLVM version ClangSharp is built against (21). This could find a wrong-version system library or fail entirely.

2. Default resolver can't find co-located libraries: The SafeDirectories search path should include the assembly's directory, but this doesn't work reliably for dotnet tools — especially AOT-compiled executables run from the NuGet cache via dotnet tool run. Both libclang.so and libClangSharp.so are co-located with the executable but never found.

Fix

1. Remove TryResolveClang entirely. The versioned SONAME approach was inherently fragile (breaks with every LLVM major version bump, different distros use different naming conventions). The method was also unnecessary — when it returned IntPtr.Zero, the default resolver should have handled it.

2. Explicitly search the assembly's own directory. After the user-provided ResolveLibrary event, try loading from Path.GetDirectoryName(assembly.Location). This handles all native dependencies (libclang, libClangSharp) uniformly on all platforms, without needing versioned SONAMEs or LD_LIBRARY_PATH workarounds.

private static IntPtr OnDllImport(string libraryName, Assembly assembly, DllImportSearchPath? searchPath)
{
    if (TryResolveLibrary(libraryName, assembly, searchPath, out var nativeLibrary))
        return nativeLibrary;

    var assemblyDir = Path.GetDirectoryName(assembly.Location);
    if (assemblyDir is not null && NativeLibrary.TryLoad(Path.Combine(assemblyDir, libraryName), out nativeLibrary))
        return nativeLibrary;

    return IntPtr.Zero;
}

This is a follow-up to #586 which was closed as resolved by the RID-specific tool package support (20.1.2.2+). While the RID package mechanism correctly makes native binaries available alongside the executable, the custom resolver prevented the default resolution path from finding them on Linux.

[tannergooding]

Will get to looking at this (and other PRs) tomorrow. Sorry for the delay, I've been fairly heads down with everything going on.

[tannergooding]

We explicitly want to keep this functionality.

I'm fine with explicitly trying the application directory first on non-Windows (which then is similar to SafeDirectories for Windows which is application directory, %windir%\system32, and user directories in the dll search path)

But we do want to search the system folder still otherwise and check for the various names it can bind to there

[tannergooding]

Since LoadLibraryHelper on unix ignores the flags, we'd rather want to effectively do something like

if (!RuntimeInformation.IsOSPlatform(OSPlatform.Windows))
{
    if (searchPath.GetValueOrDefault().HasFlag(DllImportSearchPath.ApplicationDirectory))
    {
        // Try the names using AppContext.BaseDirectory
    }

    // Try the standard variations
}

For apple target we want to try just the name + .dylib

For Linux we want to try the 3 variations already covered, in that order; first for app directory then for the normal system search