fix: Don't load SentryNative on unsupported platforms

[jpnurmi]

TLDR; default Sentry.Native.IsEnabled to false for unsupported Native AOT platforms.

The existing integration-test/aot.Tests.ps1 works great for testing unsupported platforms with a minor tweak to allow specifying the desired target RuntimeIdentifier in the environment. It only tests dotnet publish for a minimal Sentry console app, and that the compiled binary executes ok (without capturing any native exceptions). The original purpose was to test that libsentry-native.a doesn't have problematic dependencies (libcurl.so), but the same integration test works just as well for testing that sentry-dotnet doesn't try to load a non-existent libsentry-native.so.

Without the newly introduced changes that make Sentry.Native.IsEnabled default to false for unsupported Native AOT platforms, the test would produce such failures:

win-x86 (Windows 32-bit)

  Debug: This looks like a Native AOT application build.
Unhandled exception. System.DllNotFoundException: Unable to load DLL 'sentry-native' or one of its dependencies: The specified module could not be found.
   at System.Runtime.InteropServices.NativeLibrary.LoadLibErrorTracker.Throw(String) + 0x42
   at Internal.Runtime.CompilerHelpers.InteropHelpers.FixupModuleCell(InteropHelpers.ModuleFixupCell*) + 0xdf
   at Internal.Runtime.CompilerHelpers.InteropHelpers.ResolvePInvokeSlow(InteropHelpers.MethodFixupCell*) + 0x29
   at Internal.Runtime.CompilerHelpers.InteropHelpers.ResolvePInvoke(InteropHelpers.MethodFixupCell*) + 0xb
   at Sentry.Native.C.sentry_options_new() + 0x13
   at Sentry.Native.C.Init(SentryOptions) + 0x17
   at Sentry.SentrySdk.InitNativeSdk(SentryOptions) + 0x1e
   at Sentry.SentrySdk.InitHub(SentryOptions) + 0x179
   at Sentry.SentrySdk.Init(Action`1) + 0x2d
   at Program.<Main>$(String[] args) + 0x3e

linux-arm (Linux ARM 32-bit)

  Debug: This looks like a Native AOT application build.
Unhandled exception. System.DllNotFoundException: Unable to load shared library 'sentry-native' or one of its dependencies. In order to help diagnose loading problems, consider using a tool like strace. If you're using glibc, consider setting the LD_DEBUG environment variable:
sentry-native.so: cannot open shared object file: No such file or directory
libsentry-native.so: cannot open shared object file: No such file or directory
sentry-native: cannot open shared object file: No such file or directory
libsentry-native: cannot open shared object file: No such file or directory

   at System.Runtime.InteropServices.NativeLibrary.LoadLibErrorTracker.Throw(String) + 0x5b
   at Internal.Runtime.CompilerHelpers.InteropHelpers.FixupModuleCell(InteropHelpers.ModuleFixupCell*) + 0x16f
   at Internal.Runtime.CompilerHelpers.InteropHelpers.ResolvePInvokeSlow(InteropHelpers.MethodFixupCell*) + 0x3d
   at Sentry.Native.C.sentry_options_new() + 0x1f
   at Sentry.Native.C.Init(SentryOptions) + 0x29
   at Sentry.SentrySdk.InitNativeSdk(SentryOptions) + 0x31
   at Sentry.SentrySdk.InitHub(SentryOptions) + 0x1e9
   at Sentry.SentrySdk.Init(Action`1) + 0x49
   at Program.<Main>$(String[] args) + 0x69
qemu: uncaught target signal 6 (Aborted) - core dumped

Note: These two platforms were chosen because both are straightforward to set up for testing. If either platform becomes supported in the future, the respective matrix item can be removed.

Resolves: #4343

[jamescrosswell]

LGTM - thanks @jpnurmi !

[Flash0ver]

thanks @jpnurmi for the many improvements around CI and Native
I got 4 non-blocking comments