[cdac] Deploy cdac with SOS in .NET 10

[lambdageek]

Part of #99298

We would like to ship the cdac together with SOS and to allow SOS to load and use the cdac instead of the brittle DAC in .NET 10. This issue tracks the runtime changes necessary, and summarizes the SOS changes.

• Rename cdacreader.dll to mscorcdac.dll (see comments new name is still up in flux)
• Remove brittle DAC ability to load & delegate to cDAC
• Remove the cdacreader_ entrypoints from mscorcdac
• Define a ICLRRuntmeSymbol IDL interface with a TryGetSymbol API (for finding the cDAC machine descriptor from a target image) - Add CDAC support to SOS diagnostics#5392
• Add a CLRDataCreateInstance entrypoint to cdac and use it to instantiate the ContractDescriptorTarget and the SOSDacImpl Create cDAC entrypoint same as DAC CLRDataCreateInstance #112583
• Publish mscorcdac.dll in a transport packages.
  We will need one per supported SOS platform (that is, platforms where SOS can run, not platforms that it can debug)
• (nice to have) [cdacreader] Simplify build order and dependencies #104158

Summary SOS changes:

• Add a command to select cdac vs brittle DAC
• Pull the apropriate platform-specific mscorcdac.dll from the transport nuget feed and consume it in the SOS build and publish mscorcdac.dll together with SOS
• Implement the ICLRRuntimeSymbol::TryGetSymbol API on the ICLRDataTarget passed to CLRDataCreateInstance
• Load and instantiate cdac instead of the brittle DAC, if enabled
• Work with WinDbg to change how SOS is inserted and consumed

A related issue #108553 is tracking the work to implement in cdac the DAC APIs needed by SOS and CLRMA

[dotnet-policy-service]

Tagging subscribers to this area: @tommcdon
See info in area-owners.md if you want to be subscribed.

[lambdageek]

The entrypoint would be

STDAPI CLRDataCreateInstance(REFIID iid, ICLRDataTarget* target, void** iface);

Where iid will be one of the ISOSDacInterfaceNN interfaces

The cdac as currently imagined needs two things to get going:

1. A way to read from the target address space
2. The address of the contract descriptor which is a symbol with the name DotNetRuntimeContractDescriptor

We can get the former using ICLRDataTarget::ReadVirtual.

For the latter we could QI target for an interface like this:

interface ICLRRuntimeSymbol : IUnknown
{
   HRESULT TryGetSymbol([in] LPCSTR symbolName, [out] CLRDATA_ADDRESS* address);
}

similar to what the brittle DAC does with ICLRRuntimeLocator

[noahfalk]

I assume when SOS is targetting downlevel runtimes it would still load an older brittle DAC?

[lambdageek]

I assume when SOS is targetting downlevel runtimes it would still load an older brittle DAC?

I think there's two separate answers:

1. In the long term, SOS should have some kind of a policy. For example: try the cdac and if it returns E_NOTIMPL or some other error code, try a brittle DAC. (I'm not sure what a reasonable policy might be)
2. For the purposes of trying things out, @mikem8361 and I were talking about having some gesture (ie: you have to run some SOS command) to opt into the cdac.