Fix NativeAOT dependent handle secondary access with standalone GC

[jbevain]

Summary

Fix NativeAOT dependent handle secondary get/set helpers to go through IGCHandleManager instead of the CoreCLR handle-table helper functions directly.

RhpHandleAllocDependent already creates dependent handles through the active IGCHandleManager, which is required for standalone GC support. However, RhHandleGetDependent and
RhHandleSetDependentSecondary accessed the secondary object through the CoreCLR global helpers:

GetDependentHandleSecondary(handle)
SetDependentHandleSecondary(handle, secondary)

That assumes the handle is a CoreCLR handle-table handle. With standalone GC enabled, the handle belongs to the standalone GC handle manager, so secondary-object access must use the
same handle-manager abstraction as allocation, free, primary store, and extra-info access.

Details

This changes:

RhHandleGetDependent
RhHandleSetDependentSecondary

to call:

GCHandleUtilities::GetGCHandleManager()->GetDependentHandleSecondary(handle)
GCHandleUtilities::GetGCHandleManager()->SetDependentHandleSecondary(handle, secondary)

For the built-in GC handle manager this preserves existing behavior, since the manager implementation forwards to the same CoreCLR helpers internally. For standalone GC
implementations, it lets the active handle manager interpret its own dependent-handle representation.

[Copilot]

Copilot encountered an error: Your billing is not configured or you have Copilot licenses from multiple standalone organizations or enterprises. To use premium requests, select a billing entity via the GitHub site, under Settings > Copilot > Features.

[dotnet-policy-service]

Tagging subscribers to this area: @agocke, @dotnet/ilc-contrib
See info in area-owners.md if you want to be subscribed.

[jkotas]

Thanks!