Fix OS-level thread priority degradation in InProcess executors

[cloudsealed]

Fixes #2706.

When running InProcess benchmarks (with InProcessEmitExecutor or InProcessNoEmitExecutor), the benchmark elevates process and thread priority via TrySetPriority and then aggressively restores the previous priority in a finally block.
However, TrySetPriority suppresses Win32Exception when the elevation fails (which is common on Linux/Unix systems without CAP_SYS_NICE where ProcessPriorityClass.High maps to -11 nice).
As a result, if the user starts the benchmark with a slightly elevated priority (e.g. nice -n -1), the elevation silently fails, but the restoration to ProcessPriorityClass.Normal (mapped to 0 nice) succeeds, permanently degrading the process and thread priority for all subsequent benchmark runs.

This PR fixes the issue by capturing the boolean success result of TrySetPriority and ensuring we only attempt to restore the priority if the initial elevation actually succeeded.

[cloudsealed]

Good catch @timcassell! Rebased onto master and removed the unrelated PhysicalMemoryInfo changes. The PR now contains only the thread priority fix.

[timcassell]

Thanks @cloudsealed.