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

Allows the TypeNameBuidler and SigFormat to depend on the abstract target

…egistry -> ContractRegistry