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.