At present, NativeAOT does not account for availability of multiple processor groups on Windows 11+. For instance, Environment.ProcessorCount returns either 64 or 16 on an 80 core Ampere machine. Furthermore, setting DOTNET_GCCpuGroup=1 has no effect, because we access that setting (RhInitialize ⭢ PalInit ⭢ GCToOSInterface::Initialize ⭢ InitCPUGroupInfo ⭢ GCConfig::GetGCCpuGroup) before it is initialized (RhInitialize ⭢ InitDLL ⭢ RedhawkGCInterface::InitializeSubsystems ⭢ GCHeapUtilities::InitializeDefaultGC ⭢ GC_Initialize ⭢ GCConfig::Initialize).

This PR changes the NativeAOT runtime to use the same logic regarding multiple processor groups as in CoreCLR. Namely, it allows the DOTNET_GCCpuGroup configuration setting to control whether the runtime may use all processor groups. If the setting is not provided, it defaults to true for a non-affinitized process on Windows 11+ with multiple processor groups and to false otherwise (see related #68639 for CoreCLR).

To fix the issue with accessing GCConfig before it is initialized, we now call GCConfig::Initialize before doing GCToOSInterface::Initialize. That makes the behavior of NativeAOT consistent with that of CoreCLR and the standalone GC case.

However, that means that GCConfig::Initialize can no longer check the PalGetProcessCpuCount() > 1 condition to choose the ServerGC configuration value (since the CPU count depends on GCToOSInterface::Initialize, which has not been called yet). Arguably, that wasn't good design, and this PR avoids this circular dependency by keeping the ServerGC configuration value intact and choosing between SVR and WKS modes when we actually initialize the GC.

This PR also removes the unused g_fHadSingleProcessorAtStartup flag and enables the GetGroupForProcessor function for NativeAOT.