[Local GC] Refactor usage of GC-internal functions in the DAC

[swgillespie]

Partially addresses/works around https://github.com/dotnet/coreclr/issues/12170. Not quite ready for review, testing the CI and doing debugger test + manual validation right now.

[swgillespie]

@dotnet-bot test Tizen armel Cross Debug Build
@dotnet-bot test Windows_NT x64 Debug Build and Test

[swgillespie]

reviving this now that some dust has settled - @Maoni0 @adityamandaleeka @jkotas @sergiy-k PTAL? (Also @noahfalk for the DAC changes?) This approach has worked for me locally - I'm in the process of running the debugger test suite with these changes (unfortunately I'm having some trouble getting it running but working through it).

This PR explicitly tags the six functions whose symbol names and semantics are known to the DAC using the GC_DAC_VISIBLE and GC_DAC_VISIBLE_NO_MANGLE macros. These symbols are exposed to the dac using the debug/daccess/gcinterface.dac.h header. Ultimately, this means that the DAC needs to link against DAC-ized versions of these functions, which is not optimal but seems to be the simplest solution for now that allows standalone GC work to continue. Fortunately, as a part of this PR, the set of files in the gc directory that need to be built as part of the DAC build has been reduced to only handletable.cpp, handletablescan.cpp, handletablecore.cpp, and objecthandle.cpp. Notably, it's not necessary to build the GC itself.

The rest of this PR proceeds similarly to #9255, where DAC-only clones of structs are added to gcinterface.dac.h and used by the DAC to interface with the "real" structs in the debuggee. I have tried to move all fields accessed by the DAC to the start of these structs, except for one where a comment specifically indicated that this should not be done for performance reasons.

[swgillespie]

@dotnet-bot test this please

[swgillespie]

My remaining debugger test failure is failing on master so this PR is now free of test failures.

[swgillespie]

thanks!