GetTFM doesn't map PowerShell 7.6+ to net10.0 #123

On PowerShell 7.6 (which runs on .NET 10), `GetTFM` in `Get-SentryAssembliesDirectory.ps1` has no branch for 7.6, so it falls through to the `>= '7.5'` branch and returns `net9.0`. The module loads the .NET 9-targeted `Sentry.dll` into a .NET 10 runtime, which triggers `Add-Type` to print:

```
Add-Type: error CS1701: Assuming assembly reference 'System.Runtime, Version=9.0.0.0, ...' used by 'Sentry' matches identity 'System.Runtime, Version=10.0.0.0, ...' of 'System.Runtime', you may need to supply runtime policy
Add-Type: Cannot add type. Compilation errors occurred.
```

CS1701 is officially a warning, but `Add-Type` on pwsh 7.6 / .NET 10 surfaces it as a fatal compilation error. The downstream consequence is that the C# `SentryEventProcessor_` base type never gets created, which then cascades into all the `ParserError: Unable to find type [SentryEventProcessor]` noise on module import (tracked separately in #124). Colleagues on pwsh 7.5 hit the `>= '7.5' → net9.0` branch where the assembly target matches the runtime exactly, so they see neither the CS1701 nor the cascade.

Fix

Add a branch for 7.6 → `net10.0` in `GetTFM` and update the version-mapping comment block.

This depends on the bundled sentry-dotnet SDK shipping a `net10.0` build. The currently pinned 5.16.1 does not (its highest is `net9.0`); the latest Sentry 6.5.0 does. So this fix is gated on bumping the SDK — see #125 (and the Dependabot automation in #126 to keep it from drifting in the future).

Originally filed as 'silence the CS1701 warnings'; rewritten after diagnosing the real root cause.