Fix libClang resolution on Linux when co-located in RID tool packages

The TryResolveClang method on Linux only tried versioned SONAME names
(libclang.so.20, libclang-20, libclang.so.1) but never the plain
libclang.so filename. This prevented ClangSharpPInvokeGenerator from
finding the native library when running from a RID-specific dotnet tool
package (e.g. ClangSharpPInvokeGenerator.linux-x64), where libclang.so
is placed in the same directory as the native executable.

On Windows, LoadLibrary searches the app's base directory by default, so
libclang.dll next to the executable was found without issue. On Linux,
dlopen does not search the executable's directory. The SafeDirectories
DllImportSearchPath should add it, but adding an explicit fallback to
libclang.so ensures resolution works in all scenarios, including when
the tool runs from the NuGet cache via 'dotnet tool run'.

Relates to #586 (which was closed as resolved, but the fix was incomplete).

Author: Happypig375

sources/ClangSharp.Interop/clang.cs

@@ -43,7 +43,8 @@ private static bool TryResolveClang(Assembly assembly, DllImportSearchPath? sear
         {
             return NativeLibrary.TryLoad("libclang.so.20", assembly, searchPath, out nativeLibrary)
                 || NativeLibrary.TryLoad("libclang-20", assembly, searchPath, out nativeLibrary)
-                || NativeLibrary.TryLoad("libclang.so.1", assembly, searchPath, out nativeLibrary);
+                || NativeLibrary.TryLoad("libclang.so.1", assembly, searchPath, out nativeLibrary)
+                || NativeLibrary.TryLoad("libclang.so", assembly, searchPath, out nativeLibrary);
         }
 
         nativeLibrary = IntPtr.Zero;