[cdac] break up cdacreader into 4 separate assemblies

[lambdageek]

Break up the monolithic cdacreader assembly into three parts:

1. Microsoft.Diagnostics.DataContractReader.Abstractions just the API surface for contract implementations and clients note everything is internal for now (with IVT for the other assemblies) - we're not committing to a public API surface yet
2. Microsoft.Diagnostics.DataContractReader.Contracts: the concrete implementations of the contracts and data
3. Microsoft.Diagnostics.DataCotnractReader: a concrete Target that ties everything together
4. cdacreader just the unmanaged entrypoints and the legacy DAC API surface SOSDacImpl

To untangle things I had to add a new IContractFactory<TProduct> interface - this is what the target's Registry uses to instantiate specific versions of contracts.

Goals:

1. Make it possible to mock a ITarget and its IRegistry so that concrete contracts can be tested in isolation for example by making dummy dependent contracts that return canned answers.
2. Eventually make it possible to inject additional contract implementations into a Registry implementations
3. Make it possible to consume just the Target and Contracts without the unmanaged entrypoints or the legacy interfaces

Incidentally depends on #106413, although things could probably be teased apart if we want to take this PR first

[dotnet-policy-service]

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